Beruflich Dokumente
Kultur Dokumente
Banca Examinadora:
-i-
- ii -
Resumo
Este sistema visa propiciar uma assistncia tcnica eficiente, diagnosticando problemas em
campo com rapidez e confiabilidade, substituindo os simuladores manuais atuais que so
adaptados para um nico modelo de centralina e dependem de outros equipamentos como
um osciloscpio para visualizao dos sinais de interesse.
Alm de substituir todo um conjunto desses simuladores por um nico sistema, nossa
abordagem tambm oferece a possibilidade de efetuar testes dinmicos e fornece uma
ferramenta que atenda a diversos usurios com diferentes necessidades. Outras
caractersticas a serem apresentadas pelo nosso sistema so portabilidade, adequao ao
ambiente industrial e flexibilidade, para permitir uma fcil atualizao a novos
equipamentos de aquisio de dados (preveno contra a obsolescncia).
Summary
This work describes the development of a PC-based system, who simulates an automotive
environment for Electronic Fuel Injection Control Units (EFIs) and acquires information about
their acting over the vehicle. The user is able to control several parameters of the simulated
environment and verify the EFI performance through an interactive graphical interface,
accessible by mouse.
This system intends to provide an eficient technical support, promptly and reliably diagnosing
field problems, replacing the existing manual simulators. Indeed, these manual simulators are
generally adapted to a single EFI model and hang upon other equipments such as an
osciloscope for singals visualization.
The solution presented in this work intends to replace a hole set of these manual simulators for
a single system, with the capability of performing dynamic tests, being a tool to supply
different users with different requirements. Other outstanding characteristics of the developed
system are portability, industrial environment compliance and flexibility, to allow easy
upgrade to new data acquisition equipments.
- iii -
What kind of man would live where there is no daring?
I don't believe in taking foolish chances,
but nothing can be accomplished without taking any chance at all.
Charles Augustus Lindbergh (1902 1974)
Tudo o que uma pessoa possa imaginar, outras podem tornar real.
Jlio Verne (1828 1905)
- iv -
A todos os meus familiares e amigos
-v-
Agradecimentos
Aos muitos amigos de faculdade e do Laboratrio de Pesquisas Magneti Marelli que, por sua
participao nesse trabalho ou simplesmente por estarem por perto nessa importante etapa
da minha vida, so co-responsveis pela minha formao intelectual e moral, especialmente
mas no somente a rico de Lima Azevedo, Danilo Barreto de Arajo, Cleber Akira
Nakandakare, Jorge Arturo Polar Seminrio, Danielle Melo,
Marcos Vinicius Gil Gomes, Marcos Mauricio Pelcia, Marcelo Arturo Jara Perez,
Leandro Ferrari Crocomo e Luiz Alberto Castro de Almeida.
Aos meus pais, irmos e avs por me darem as condies materiais e psquicas para o meu
desenvolvimento pessoal e social.
- vi -
ndice Geral
Captulo 1 Introduo........................................................................................................ 1
1.1 Um panorama da eletrnica automotiva ...................................................................... 1
1.2 Motivao do Projeto ................................................................................................... 3
1.3 Metodologia................................................................................................................. 9
Captulo 2 Unidade de Controle de Injeo e Ignio Eletrnicas ..................................... 13
2.1 Conceitos Bsicos ..................................................................................................... 13
2.2 Modo de atuao ....................................................................................................... 15
Captulo 3 Elaborao das Especificaes........................................................................ 19
Captulo 4 Arquitetura do Sistema................................................................................... 23
4.1 Definio de Plataformas de Hardware e Software ..................................................... 27
Captulo 5 Modelamento.................................................................................................. 29
5.1 Modelo de Requisitos Diagramas de Use Cases ....................................................... 33
5.2 Modelo de Objetos do Domnio do Problema Diagrama de Classes .......................... 35
5.3 Modelo Dinmico Diagramas de Objetos ................................................................. 39
5.4 Modelo Dinmico Diagramas de Estados ................................................................ 41
5.5 Modelo Fsico Diagramas de Componentes e de Implantao .................................. 45
5.6 Resumo da Aplicao da UML com LabVIEW 4.1....................................................... 47
Captulo 6 Realizao do Software ................................................................................... 49
6.1 Descrio da forma de utilizao do Sistema ............................................................. 51
Instalao .................................................................................................................... 51
Controle de Acesso ao Sistema..................................................................................... 51
Identificao do Usurio .............................................................................................. 52
Engine ......................................................................................................................... 53
About ........................................................................................................................... 53
Gerenciador de Componentes ...................................................................................... 53
Gerenciador de Produtos.............................................................................................. 58
Executar Teste (Simulao) .......................................................................................... 60
Documentao ............................................................................................................. 63
6.2 Descrio do cdigo-fonte.......................................................................................... 65
Atuadores de Freqncia: ............................................................................................ 70
Atuadores de Potncia:................................................................................................. 71
Sensores de Freqncia: .............................................................................................. 72
Atuador de Marcha Lenta:............................................................................................ 77
Transdutores: .............................................................................................................. 80
Captulo 7 Realizao do Hardware.................................................................................. 85
7.1 Mdulo de Condicionamento de Sinais ...................................................................... 85
Alimentao/Referncia: .............................................................................................. 85
Atuadores: ................................................................................................................... 87
Cargas Reais:............................................................................................................... 87
Atuadores de Potncia:................................................................................................. 87
Freqncia e Marcha Lenta:......................................................................................... 88
- vii -
Sadas On-Off: ............................................................................................................. 90
Serial: .......................................................................................................................... 90
Entradas On-Off: ......................................................................................................... 91
Transdutores e Sensores:............................................................................................. 91
Captulo 8 Avaliao do Sistema ...................................................................................... 95
8.1 Parmetros dos Componentes-Exemplo e Produto-Exemplo ...................................... 95
8.2 Resultados Obtidos ................................................................................................... 99
Captulo 9 Concluses ................................................................................................... 101
9.1 Orientao para Futuras Expanses do Projeto ....................................................... 103
9.2 Trabalhos Acadmicos............................................................................................. 111
Referncias Bibliogrficas................................................................................................. 113
Apndice A Alguns Use Cases ........................................................................................ 115
Apndice B Lista de VIs ................................................................................................. 133
Na biblioteca Corefiles.llb .............................................................................................. 133
Na biblioteca DataBaseManagement.llb......................................................................... 135
Na biblioteca Security.llb .............................................................................................. 148
Na biblioteca Simulation.llb .......................................................................................... 149
Na biblioteca UserInterface.llb....................................................................................... 160
- viii -
ndice de Figuras
- ix -
Figura 42: GetPars.vi ......................................................................................................... 68
Figura 43: Runtest.vi (Simulation)...................................................................................... 69
Figura 44: Startup.vi .......................................................................................................... 70
Figura 45: Interact.vi.......................................................................................................... 71
Figura 46: Quadro de sinais para centralinas da famlia IAW.............................................. 74
Figura 47: RPMArray_3.vi................................................................................................... 76
Figura 48: RPMArray_3.vi (otimizao de processamento)................................................... 77
Figura 49: Motor de Passo em Movimento .......................................................................... 78
Figura 50: CheckStepPosit.vi.............................................................................................. 80
Figura 51: Transduce.vi ..................................................................................................... 81
Figura 52: Panel 1AVB76AT.vi (Modo de inicializao) ........................................................ 82
Figura 53: Panel 1AVB76AT.vi (Mostra respostas da ECU no painel) .................................. 83
Figura 54: Panel 1AVB76AT.vi (Executa modificaes do usurio) ...................................... 83
Figura 55: Panel 1AVB76AT.vi (Disponibiliza aes do usurio).......................................... 84
Figura 56: Conexo dos Rels Power Latch, Pump e Chave Key-On .................................... 86
Figura 57: Bloco Amplificador de Instrumentao .............................................................. 89
Figuras 58 e 59: Bloco Divisor de Tenso e Opo de rel para Sadas On-Off .................... 89
Figura 60: Interface Serial .................................................................................................. 90
Figura 61: Deslocadores de Nvel para Entradas em Pull-Up e Pull-Down........................... 91
Figura 62: Mdulo de Interface do AutoSEFI ...................................................................... 92
Figura 63: Plugues de conexo da bateria e chave Key-on................................................ 93
Figura 64: Cargas reais e rels de Power Latch e Pump ................................................. 93
Figura 65: Sensor MAP....................................................................................................... 95
Figura 66: Sensor T Air ...................................................................................................... 95
Figura 67: Sensor T HO .................................................................................................... 96
Figura 68: Sensor Throttle .................................................................................................. 96
Figura 69: Sonda Lambda .................................................................................................. 96
Figura 70: Cannister ......................................................................................................... 97
Figura 71: Unidades eletrnicas conectadas em rede[21] .................................................... 103
Figura 72: Modelo V ........................................................................................................ 104
Figuras 73 e 74: Bancada de testes para componentes e Breadboard para sistemas de
conforto[21] ........................................................................................................................ 105
Figuras 75 e 76: Veculo de Referncia[21] ......................................................................... 105
Figura 77: Nveis de emisso nos EUA/Europa e tecnologias para esse fim[22]................... 107
Figura 78: Componentes tpicos de sistemas PZEV & SULEV[22] ....................................... 108
Figura 79: Autosar[21] ....................................................................................................... 109
ndice de Tabelas
-x-
Captulo 1 Introduo
-1-
-2-
1.2 Motivao do Projeto
Antes de iniciarmos as consideraes sobre os fatores que geraram nosso interesse
no desenvolvimento deste ambicioso projeto, necessrio garantirmos uma compreenso
exata de alguns termos a serem utilizados. O ambiente hardware-in-the-loop (HitL) ser
melhor descrito no decorrer desta introduo. Portanto vamos s seguintes definies[13]:
Verificao: o processo de avaliao de um sistema para determinar se os produtos de
uma determinada fase de desenvolvimento satisfazem os requisitos impostos no incio
daquela fase.
Validao: o processo de avaliao de um sistema, no final do processo de
desenvolvimento do software, para determinar se ele satisfaz os requisitos funcionais
sistmicos em sua totalidade.
Ambiente Esttico de Teste: Um ambiente de teste, eletronicamente equivalente ao de
um veculo, que permite a um usurio especificar um nico e irreproduzvel conjunto de
dados de entrada para a unidade de controle automotiva.
Ambiente Dinmico de Teste: Um ambiente de teste hardware-in-the-loop (HitL), similar
a um veculo real, que permite a um usurio especificar um conjunto de dados de
entrada para a unidade de controle e/ou comandos do motorista, reproduzvel e
programvel.
Como conseqncia da evoluo das unidades de controle eletrnicas para aplicaes
automotivas, que passaram a trabalhar com microprocessadores mais poderosos,
executando mais tarefas e com algoritmos mais complicados; as rotinas de software que
controlam seu funcionamento cresceram para alm da capacidade de um ou dois
engenheiros poderem especificar, desenvolver, testar e manter todo o sistema. Para garantir
um alto nvel de qualidade no desenvolvimento dessas unidades de controle, estratgias de
verificao de software avanadas devem ser implementadas.
Os mtodos de produo de software tradicionais relegam as atividades de verificao
para o final do ciclo de desenvolvimento do produto, o que resulta em um teste dos erros do
programa. A abordagem atual reza que essas atividades devem ser realizadas a cada estgio
do seu ciclo de desenvolvimento, desde testes para cada mdulo de software at os testes
finais de integrao, permitindo a identificao de problemas com antecedncia e at
minimizando sua ocorrncia. Geralmente os nveis de testes se dividem em trs categorias:
unidade, sistema e veculo[1].
Os testes ao nvel de unidade verificam requisitos de software que necessitam de
ferramentas de teste e debugging intrusivas para demonstrar adequadamente a
conformidade do software com as especificaes de projeto. A maioria dos testes realizados
pelo grupo de Engenharia de Software pertence a esta categoria.
Os testes sistmicos requerem um ambiente de teste integrado unidade de controle
para verificar os requisitos do sistema. A maioria dos testes desta categoria realizada pelo
grupo de Engenharia de Sistemas, pois j envolve conhecimento da fsica associada ao
ambiente de atuao da unidade de controle.
-3-
J os testes veiculares requerem o uso de um veculo para demonstrar a
conformidade com as especificaes e fazer a validao final do projeto, aps avaliao do
funcionamento da unidade de controle quando em conjunto com os diversos outros sistemas
eletrnicos presentes no veculo. Esses testes so exigidos e realizados em sua maioria pelas
montadoras que so clientes desse produto.
Alm destas consideraes quanto s tarefas a serem executadas que devem ser
feitas durante as etapas iniciais de projeto, deve ser levado em conta que a qualidade dos
muitos produtos de eletrnica automotiva embarcada depende fundamentalmente da sua
confiabilidade durante TODA a sua vida til. E em um ambiente extremamente agressivo e
ruidoso, o correto funcionamento dessa eletrnica depende de diversas circuitarias
auxiliares como: protees contra transientes de tenso/corrente e picos de tenso reversa;
estabilizadores da tenso de referncia (bateria); filtros para o rudo introduzido em sinais de
baixa amplitude. Alm disso, esses produtos ainda devem se adequar a diversas normas
especficas de Compatibilidade e Imunidade Eletromagntica (EMC & EMI) emitidas pelas
organizaes ISO e DIN[4]. No entanto, mesmo em um projeto que suporte tudo isso
eficientemente, ainda persistem as disfunes provocadas por componentes danificados ou
imprecisos, erros na linha de montagem, descalibrao, desgaste natural e at mesmo fadiga
mecnica devido a vibraes intensas e constantes. Apesar de algumas destas causas
poderem ser minimizadas com a adoo de programas de qualidade que garantam uma taxa
de produtos defeituosos to baixa quanto se queira, alguns problemas ocorrem
inevitavelmente em vrios produtos em circulao, e para os clientes que os adquirirem ela
ser de 100%.
Uma forma de minimizar essa insatisfao em potencial prover aos clientes uma
assistncia tcnica eficiente, capaz de resolver a maioria destes problemas com rapidez, onde
quer que ele se encontre. Isso pressupe a existncia de um sistema capaz de efetuar
diversos testes em campo e utilizar as funes de diagnstico prprias do produto a fim de
identificar o problema e solucion-lo, quando possvel, ou indicar que o produto deve ser
trocado.
Os equipamentos utilizados atualmente para satisfazer a ambos os requisitos:
auxiliar no projeto de novas unidades de controle e funcionar como ferramenta de
diagnstico para assistncia tcnica; podem ser classificados basicamente em simuladores
estticos ou dinmicos (HitL). Deve ser enfatizado que nenhum destes equipamentos
pretende e nem tem a capacidade de substituir completamente os testes veiculares.
Os simuladores estticos atuais contm circuitos eletrnicos que fornecem cargas
eltricas equivalentes quelas encontradas em um veculo real. Esses simuladores so
montados em caixas nada portteis, cujo Painel Frontal contm potencimetros, chaves e
outros controles para produzir os sinais de excitao comandos do motorista (chave de
partida, posio do pedal do acelerador/borboleta, etc.) e sinais dos sensores (rotao do
motor, temperatura do lquido de arrefecimento, etc.) e LEDs para monitorar as sadas
referentes pela centralina em questo, pois eles so projetados para atender a um nico
modelo em particular. O operador deve variar cada sinal manualmente, tentando executar
um padro de teste, porm sem o compromisso de reproduzir uma situao real ou possvel.
-4-
Dessa forma a repetibilidade dos testes, que podem requerer padres de dados
complexos, depende da habilidade do operador em ajustar estes dispositivos.
Adicionalmente, esses simuladores no tm capacidade de gerar a resposta do veculo
resultante dos comandos da centralina sobre seus atuadores. Eles devem ser utilizados junto
com osciloscpios, multmetros e outros instrumentos para visualizao dos sinais de
interesse e tambm podem ser utilizados junto com um PC para ativar funes internas de
diagnstico e obter informaes sobre falhas detectadas pela centralina atravs de uma linha
serial. Os simuladores estticos tambm no permitem a gerao de documentao de teste
devido sua incapacidade de aquisio de dados[1][5].
Um simulador HitL (ou mais simplesmente HiL) emula os sensores e atuadores de
um sistema de controle para recriar um ambiente de operao, similar a um veculo real,
porm de uma forma controlada. Idealmente, a unidade de controle deve ser incapaz de
distinguir o ambiente de simulao de um ambiente real. Os elementos bsicos de um
simulador HiL podem ser categorizados em mquina de processamento, recursos de
entrada/sada (E/S), condicionadores de sinal e interface com o usurio, conforme podemos
ver na Figura 1. As mquinas de processamento realizam as tarefas de planejamento dos
sinais no tempo de acordo com scripts de teste, execuo de modelos dinmicos e aquisio
de dados interna. Os cartes E/S so tipicamente conversores analgico-digitais e digital-
analgicos, oferecendo resoluo de 12 ou 16 bits, bem como linhas digitais TTL.
Condicionadores de sinal realizam as operaes necessrias para enviar/receber sinais
da/para a unidade de controle. Finalmente a interface do usurio o meio para comunicar
informaes de/para o usurio ou computadores externos. Atividades podem incluir a
criao de scripts de teste, definio de critrios pass/fail, execuo de testes e apresentao
de resultados graficamente. Esses quatro elementos unidos fornecem um ambiente para
repetir seqncias de teste de forma precisa para efetivamente investigar e documentar a
operao de uma unidade de controle[5].
-5-
Ethernet
Conversores Emulao de
Atuador
Computador processadore Sistema de
s Linhas Controle
Host
DSPs Emulao de
Conversores Sensor
Elementos de
Processamento
Recursos de E/S Condicionamento
- Chaves e Potencimetros
de Sinais e Cargas
- Interfaces Grficas de Usurio
- Scripts de Teste Eltricas
- Apresentao de Dados de Teste
Interface de
- Modelos Dinmicos Instrumentao Externa
Usurio
-6-
9 Um modelamento dinmico do comportamento do veculo e atividades de verificao da
unidade de controle utilizando-se de scripts de teste requerem o fornecimento e aquisio
de sinais para/do controlador em tempo real. Para atingir caractersticas de tempo real, o
tempo de execuo de um lao de simulao dever ser inferior a 0,1, sendo a
constante de tempo mais rpida na dinmica dos subsistemas veiculares ou o tempo de
execuo do lao de controle da unidade eletrnica. Um lao de simulao se inicia com a
mquina de processamento realizando a leitura dos dados de E/S da unidade de controle
atravs da interface de hardware existente (recursos de E/S e condicionamento de sinais).
Em seguida estes dados so processados para se avaliar a dinmica do sistema, os
valores fornecidos atravs da GUI so checados e um novo conjunto de dados para
atualizao do ambiente simulado disponibilizado para escrita. Durante essa etapa, os
dados adquiridos e os que sero simulados, bem como variveis intermedirias de
simulao, devem estar disponveis para armazenamento e a GUI deve ser atualizada.
Finalmente os sinais especificados pela mquina de processamento so enviados
unidade de controle atravs da interface de hardware. O sistema operacional deve ser
capaz de manter a temporizao do lao de simulao e sinalizar passos omitidos.
9 A GUI deve ser amigvel e permitir reconfigurao do painel frontal para atender a
diferentes usurios. Haver cinco modos de operao da GUI: manipulao direta dos
sinais do simulador atravs de botes, chaves e controles de rolagem e observao dos
resultados; gravao desses sinais de entrada para posterior reproduo; criao de um
script de teste na GUI com um clock artificial para simulao em tempo real; execuo de
scripts de teste preexistentes em tempo real com data logging sincronizado-temporizado e
visualizao de dados adquiridos em simulaes anteriores.
Nosso objetivo aqui ser desenvolver um sistema capaz de efetuar testes em diversos
produtos de eletrnica automotiva, sendo que focaremos nosso prottipo em unidades de
controle de injeo e ignio eletrnicas, que doravante denominaremos de centralinas. O
sistema ser um simulador de todo o ambiente do veculo perante as centralinas, verificando
seu comportamento em uma situao de funcionamento pseudo-real, conforme os conceitos
de simuladores HiL discutidos acima. Toda a comunicao entre o simulador e a centralina
dever ser feita atravs do seu conector.
Os equipamentos que foram tomados como parmetro de desenvolvimento, so os
simuladores estticos utilizados pela Magneti Marelli do Brasil primariamente para
atividades de assistncia tcnica junto s montadoras de veculos suas clientes. Outros
equipamentos que apresentam caractersticas de simulao dinmica ainda estavam em
desenvolvimento na matriz desta empresa e foram projetados para atender primordialmente
suas necessidades locais, sem levar em conta as particularidades do mercado brasileiro.
-7-
Nossa abordagem visa no somente substituir todo um conjunto dos simuladores
estticos atuais por um nico sistema porttil, como tambm oferecer as possibilidades de
efetuar testes dinmicos e registrar os resultados obtidos sem o auxlio de outros
equipamentos, fornecendo ferramentas configurveis por software que atendam s
necessidades de diferentes usurios. Adicionalmente o sistema deve ser modular, para ser
utilizado em diversas centralinas reaproveitando configuraes anteriores, e flexvel, para
permitir uma fcil atualizao a novos equipamentos de aquisio de dados. Eventualmente
no iremos atender a todas as caractersticas dos simuladores HiL citados acima, para nos
atermos s necessidades reais do mercado brasileiro: tanto atuais quanto esperadas.
Como a descrio de um sistema desse porte ficaria incompleta se nos limitssemos
s possibilidades dessa dissertao em papel, acrescentamos um CD no encarte que contm
diversas informaes complementares bem como todo o cdigo-fonte do software gerado no
escopo deste trabalho.
-8-
1.3 Metodologia
Para atender as caractersticas de um simulador HiL mencionadas no Item 1.2 acima
com a melhor relao custo-benefcio, optamos desde o incio pela utilizao de conceitos de
co-projeto hardware-software. O interesse em metodologias que se utilizem destes conceitos
tem aumentado medida que os sistemas digitais crescem em complexidade e aumenta a
disponibilidade de tecnologias de implementao, trazendo a necessidade de um
balanceamento dos prs e contras nas decises de se utilizar elementos hardware ou
software para cada funcionalidade. Essas novas metodologias de projeto requerem que
software e hardware sejam co-projetados buscando otimizao com respeito a desempenho e
custo. Podemos citar trs aspectos principais que tem estimulado o interesse nesta rea:
9 A necessidade de sistemas computacionais mais eficientes perante o usurio, podendo
requerer arquiteturas particulares para sistemas operacionais ou hardware mais
adaptado ao software que se executa sobre ele;
9 Novas arquiteturas baseadas em circuitos programveis de hardware podem melhorar a
velocidade de execuo de operaes especficas ou emular o projeto de novos sistemas
hardware;
9 Progressos recentes em ferramentas de sntese e simulao para circuitos hardware vm
abrindo caminho para a integrao de ambientes CAD ao co-projeto hardware-
software[6][7].
-9-
Apesar de que os conceitos e metodologias mencionados acima so utilizados mais
freqentemente para projetos de sistemas embutidos digitais fato evidenciado em alguns
termos utilizados na Figura 3, como sntese de hardware, p.e. , consideramos que a
abordagem ainda permanecia vlida. Pela natureza distinta do nosso sistema, no
poderamos utilizar nenhuma das ferramentas de co-projeto disponveis atualmente, no
entanto levar em considerao esses conceitos, por si s j trazia benefcios suficientes para
justificar sua utilizao. Alguns exemplos de decises de projeto relacionadas a
particionamento hardware software seriam, por exemplo:
o tipo de conversores A/D e D/A a se utilizar conversores simples, que trabalham com
valores digitais cujo escalamento deve ser feito em software, conversores inteligentes
configurveis para uma variedade de nveis de tenso de operao ou mesmo conversores
com diversas entradas/sadas multiplexadas.
Filtragem/processamento dos dados adquiridos em hardware, software de baixo-nvel
(microprocessador, DSP) ou software de alto-nvel (computador pessoal)
- 10 -
Especificao do Sistema
Elaborao de Algoritmos
Particionamento
Hardware-Software
Sntese de Interface:
1. Insero de pilhas, latches,
decodificadores de endereo Software p/
Configurao Componentes
do Hardware 2. Cdigo para operaes E/S
e sincronizao de Programveis
semforos
Hardware-Software Interface
Simulao do Sistema
Atende No Reparticionamento e
Especificaes Busca de Alternativas
Sim
Figura 3: Esquema de Co-Projeto Hardware-Software
- 11 -
- 12 -
Captulo 2 Unidade de Controle de Injeo e Ignio Eletrnicas
- 13 -
- 14 -
2.2 Modo de atuao
A quantidade de combustvel a ser injetado deve manter a razo ar-combustvel da
mistura em torno do valor estequiomtrico =14,4 (que corresponde razo relativa =1).
Uma mistura com 10% de excesso de ar (=1,1) requerida para queimar todo o combustvel
presente, resultando em mxima economia, enquanto que uma mistura com 10% de excesso
de combustvel (=0,9) requerida para queimar todo o oxignio, resultando em mxima
potncia[10][11].
Com informaes provenientes dos sensores de rotao, temperatura e presso do ar,
e valores de calibrao, as centralinas calculam a quantidade de ar entrante no motor a cada
ciclo atravs de um mtodo de medida indireta conhecido como regime motor densidade de
ar aspirado, ou speed density[12]. Esse mtodo se baseia no clculo da massa de ar aspirado
para determinao da massa de combustvel a ser injetado que garanta a titulao desejada
da mistura. As principais equaes envolvidas neste clculo esto mostradas abaixo:
RPM
VR = V VT = V cc (1)
2
Vr o volume real de ar aspirado por ciclo, Vt o volume terico, V o rendimento
volumtrico e cc a cilindrada do motor.
P
M R = VR (2)
T
Mr a massa de ar aspirado por ciclo, P a presso absoluta no coletor de admisso e T a
temperatura absoluta do ar aspirado.
1 V RPM P
QC = K MR = K cc (3)
2 T
Qc a quantidade de combustvel a ser injetado, K a constante de fluxo do injetor e a
razo ar-combustvel desejada.
principalmente atravs da escolha da razo ar-combustvel, que a centralina
implementa a estratgia de gerenciamento do motor mais adequada para o momento. Por
exemplo, quando ocorrem variaes bruscas na posio da borboleta, a centralina enriquece
a mistura para obter maior potncia do motor; da mesma forma, se a borboleta permanece
fechada por um certo tempo, a centralina suspende totalmente o fornecimento de
combustvel. Alm disso, pequenas variaes na rotao do motor, presso ou temperatura
do ar, fazem com que a razo ar-combustvel efetiva seja diferente da calculada. O
monitoramento da mistura feito pela sonda lambda, que fornece o valor da razo ar-
combustvel, a partir da observao da quantidade de oxignio nos gases de escape.
- 15 -
Alm de proporcionar mximo aproveitamento do combustvel, o gerenciamento da
titulao da mistura tambm visa minimizar os nveis de emisses gasosas, principalmente
de gs carbnico (CO2). J a formao de xidos de nitrognio (NOx) aumenta
significativamente com o aumento da temperatura de combusto. Uma forma de diminuir
essa temperatura conduzir os gases de escape de volta cmara de combusto, para que
esses gases inertes diluam a mistura ar-combustvel. Essa recirculao dos gases de escape
pode ser feita de duas formas: recirculao interna, obtida com temporizao adequada das
vlvulas (overlap); ou externa, com a utilizao de vlvulas EGR. A estratgia de controle
dessas vlvulas deve regular a adio de gases de escape mantendo um alto nvel de torque,
baseando-se em informaes da posio da borboleta, rotao do motor, temperatura do
lquido de arrefecimento e presso do ar no coletor de admisso[1][13].
Alm da composio da mistura, um parmetro importante para que haja uma
combusto adequada a energia de ativao que desencadeia a exploso, fornecida pela
fasca da vela. A ECU controla a quantidade de energia armazenada no campo magntico da
bobina de ignio atravs do tempo em que ela polarizada antes de cada fasca.
Ao relacionarmos esse tempo com o tempo que dura um ciclo motor completo que
por conveno correspondem a 360 (duas voltas da rvore de manivelas, antes conhecida
como virabrequim), obtemos o chamado ngulo de Dwell.
Finalmente, a combusto da mistura no instantnea, e para melhor
aproveitamento da energia liberada na exploso, esta deveria acontecer no instante de maior
compresso da mistura. Levando-se em conta o tempo de propagao da chama, conclui-se
que a fasca deve acontecer alguns instantes antes do ponto morto superior do pisto (PMS).
Esse tempo de antecedncia, quando relacionado com o tempo de durao de uma volta da
rvore de manivelas, corresponde ao ngulo de avano. ngulos de avano menores que o
ideal (que varia conforme a condio atual do motor) representam um mal-aproveitamento
da energia da combusto, pois o pisto j estar em movimento descendente. ngulos de
avano maiores que o ideal acarretam no fenmeno de detonao ou bater-pino como o
pisto ainda est em movimento ascendente, a exploso atinge seu apogeu e fora-o para
baixo antes do PMS se opondo ao sentido de rotao do motor.
A Figura 4 a seguir mostra um diagrama simplificado para a famlia de centralinas
MIW da Magneti Marelli[14].
- 16 -
Motor de
RPM Frequncia Potncia passo 1 a 4
Velocidade Injetores
Bobinas de
ignio
Borboleta Mdulo de
Detonao Bomba
Presso Ar Baixa Lmpada de
Temp. Ar Analgico Medio Potncia advertncia
Temp. gua Cannister
Sonda O2 Clculo
EGR
V bateria Atuao
Ar Cond. Consumo
Abs Lgico Sinal Accens
Octanagem Tx
Rx
- 17 -
- 18 -
Captulo 3 Elaborao das Especificaes
Conforme descrito no Captulo 1, o sistema simulador a ser desenvolvido tem como
objetivos principais efetuar testes e identificar problemas em centralinas, solucionando-os
quando possvel. Adicionalmente, ele deve servir como ferramenta de auxlio ao projeto de
novos produtos, antecipando informaes importantes quanto ao comportamento de
prottipos sem a necessidade de submet-los a situaes reais de rodagem. O sistema deve
ser porttil e toda a comunicao entre o simulador e a centralina dever ser feita atravs de
um nico cabo.
Apesar da pretenso, esse simulador tem como objetivo final realizar uma simulao
off-line do ambiente de um veculo, ou seja, os atuadores e outros sub-sistemas complexos
seriam modelados e incorporados ao software. Entretanto, esse tipo de simulao s seria
alcanvel com a utilizao de computadores mais rpidos e processamento paralelo
utilizando multi-processadores. Devido limitao dos recursos disponveis atualmente,
necessitamos utilizar atuadores e outras cargas reais para serem conectadas centralina
assegurando seu funcionamento adequado.
O sistema deve prover gerenciamento de acesso e privilgios de usurios para evitar
mau uso do sistema por pessoal desautorizado. Dever haver somente um administrador do
sistema capaz de realizar cadastramento de usurios, adicionar e/ou remover recursos de
interface de hardware e configurar a interface de usurio. Futuras expanses do sistema
devero fornecer ferramentas de auto-configurao dos recursos de hardware e possibilidade
dos usurios personalizarem o Painel Frontal do simulador.
O sistema deve ser flexvel a ponto de permitir uma fcil atualizao a novos
dispositivos de gerao e aquisio de sinais. A capacidade inicial do sistema deve ser
suficiente para:
Simulao dos sinais de at 16 sensores analgicos (transdutores diversos,
termistores NTC e PTC, acelermetros, sondas lambda, rotao do motor, etc.) e
sua desconexo.
Simulao e verificao do estado de chaves ON-OFF e rels.
Simulao dos eventos key-on e key-off.
Cargas reais (bicos injetores, bobinas de ignio, motores de passo, etc.) para
serem conectadas e desconectadas centralina com o sistema em funcionamento.
Aquisio de at seis formas de onda de corrente com informaes de
temporizao.
Aquisio de sinais PWM e quadrature clocks.
Sua configurao para utilizao com um determinado modelo de centralina dever
ser feita totalmente por software de maneira modular, ou seja, deve haver a possibilidade de
reaproveitamento de configuraes anteriores. Nesta configurao o usurio fornece ao
sistema as caractersticas de todos os sensores e atuadores que devem ser conectados
centralina em suas condies normais de operao. Com base nas informaes de
configurao, o sistema deve emitir uma lista de conexes a fim de orientar o usurio para a
confeco do cabo que ir conectar esta centralina ao sistema simulador.
- 19 -
Os testes so executados atravs da simulao do ambiente de um veculo para as
centralinas, ou seja, o sistema deve gerar sinais eltricos correspondendo a todas as
grandezas fsicas mensuradas pelos diversos sensores que compe um determinado sistema
de injeo e ignio, criando uma situao de funcionamento pseudo-real. A verificao do
funcionamento dever ser feita primeiramente atravs do monitoramento de grandezas
eltricas em cada um dos atuadores do sistema de injeo e ignio. Como ferramenta
auxiliar, o sistema deve ser capaz de ativar e obter os resultados das funes de diagnstico
prprias de cada centralina atravs de sua linha de comunicao serial.
Para atender aos requisitos das diferentes aplicaes que pretendemos satisfazer com
este simulador, devem ser implementadas diferentes estratgias de teste: open-loop, closed-
loop e hbrido[1][15].
O teste open-loop, cujo conceito mostrado na Figura 5, corresponde simulao
esttica, onde os sinais correspondentes a cada sensor da centralina podem ser acessados e
variados manualmente de forma independente, sem o compromisso de representar um
ambiente plausvel. Esse teste aplicvel s situaes onde as condies de teste podem ser
estabelecidas pela ao direta do usurio de forma razovel. Uma suposio implcita neste
mtodo de teste, que a resposta do veculo aos comandos da centralina pode ser
desprezada, compensada ou caracterizada pela maneira que os sinais correspondentes aos
sensores so gerados ao longo do tempo. Essa suposio ganha maior embasamento com a
utilizao de scripts de teste que sero comentados a seguir.
Fluxos de Dados
- 20 -
Cada componente dentro de um subsistema pode ser descrito em diferentes nveis de
fidelidade, utilizando-se modelos de maior ordem para as dinmicas principais e de menor
ordem para as secundrias. Estes modelos podem ser analticos ou empricos de acordo com
a disponibilidade de informaes existente. No caso de subsistemas complexos, muito
difcil obter relaes paramtricas com solues em forma fechada.
Nestes casos mais conveniente a obteno de uma tabela look-up cobrindo toda a
regio de operao, porm esta poderia se tornar muito grande o que seria invivel com as
capacidades limitadas de um PC. Nesses casos deve haver uma ponderao entre a preciso
do modelo e a velocidade execuo requerida ou disponvel. Como alternativa, os dados
podem ser divididos em diferentes sries com diferentes equaes de regresso cobrindo
cada srie. Entretanto, devido s descontinuidades em suas extremidades, um nico
polinmio de maior ordem ou funo especial como exponenciais ou trigonomtricas seria
mais conveniente[2][15].
Comandos do
Motorista Modelo
Sadas da ECU
Dinnico Entradas da ECU
do Veculo Unidade de
Controle
Variveis de Simulao Gravao dos Dados da ECU
Fluxos de Dados
A estratgia hbrida de testes uma combinao das duas anteriores, onde alguns
sinais da centralina podem ser manipulados diretamente, paralelamente execuo do
modelamento dinmico do veculo produzindo os sinais remanescentes. A Figura 7 mostra
um esquemtico dessa estratgia.
- 21 -
Comandos do
Motorista Modelo
Entradas Sadas
Dinnico da ECU da ECU
do Veculo Unidade de
Entradas da Controle
ECU Gravao dos Dados da ECU
- 22 -
Captulo 4 Arquitetura do Sistema
A primeira abordagem considerada buscava desenvolver um sistema proprietrio
dedicado (mdulo de simulao), que se comunicaria com um software rodando em um
computador pessoal (PC) atravs de uma linha serial RS-232. Este mdulo seria composto
basicamente de: um microprocessador disponvel comercialmente, com interface serial RS-
232 j incorporada; memria RAM para o programa de teste; dispositivos de gerao e
aquisio de sinais analgicos (conversores D/A e A/D); temporizadores/contadores para os
sinais de freqncia, duty cycle, etc.; interface serial compatvel com a utilizada pela
centralina; entradas e sadas digitais 0-12V. Ainda so necessrias, circuitaria para
condicionar todos os sinais de entrada e sada aos nveis de tenso e corrente requeridos
pela centralina e adequados a cada dispositivo de interface e uma placa com conectores para
os dispositivos automotivos que, devido complexidade de suas caractersticas de
tenso/corrente (geralmente indutivas e variveis), so inadequados para um modelamento
matemtico e necessitam estar presentes. Tais dispositivos no simulveis so:
4 bicos injetores MPI
1 bico injetor SPI
3 bobinas de ignio
1 motor DC
1 vlvula cannister
1 vlvula EGR
4 rels automotivos
Nessa abordagem, imaginamos um banco de dados de centralinas baseado em PC.
Cada centralina seria representada por um registro contendo informaes relacionadas com
a pinagem e as rotinas de software do respectivo programa de teste a serem desembarcadas
no sistema simulador para que ele simule e adquira os sinais envolvidos. Todo o programa
de teste deve ser desembarcado no mdulo simulador antes de sua utilizao para evitar
desperdiar tempo de processamento com comunicao de dados durante a simulao,
portanto a memria RAM deve ser suficiente para acomod-lo. A Figura 8 abaixo mostra o
algoritmo bsico do sistema e indica as atividades sob responsabilidade do mdulo de
simulao. A estrutura desse mdulo de simulao pode ser vista na Figura 9.
- 23 -
Iniciar
Verificar
Usurio
Cadastrar Selecionar
Componentes Centralina
Associar
Monitorar
Componentes
Key-On
Iniciar Suspender
Finalizar Simulao Simulao
Emitir Key-Off ou
Relatrio Finaliza
Finalizar
Key-Off
Inicializao Tratamento
de Pacote
- 24 -
A funo de cada bloco na figura acima pode ser descrita como se segue:
Serial - Montagem dos bytes e teste de paridade para verificar bytes adulterados.
Gerenciador de Comunicao - Controla o enchimento do buffer e a estrutura dos
pacotes, verificando seu comprimento e checksum.
Tratamento de Pacote - Analisa o tipo de mensagem e carrega as rotinas de
simulao ou dados na rea de RAM correspondente. Tambm monta as mensagens
que devem voltar para o computador (dados adquiridos).
Inicializao - Controla o Gerenciador de Comunicao e o Tratamento de Pacote at
receber a rotina MAIN, quando deixa de atuar e lhe passa o controle.
MAIN - Software especfico para cada centralina, que gerencia o recebimento das
rotinas de simulao, fornecendo os respectivos endereos de armazenamento para o
Tratamento de Pacote. Ao trmino desse processo o responsvel pelo gerenciamento
de tarefas, dividindo o tempo de processamento entre comunicao, gerao e
aquisio de dados.
Rotinas de Simulao - Softwares especficos para cada modelo de sensor ou atuador
que quando associados a um programa MAIN, definem um modelo de centralina.
A partir dessa idia inicial, comeamos os primeiros estudos de particionamento
hardware/software. Nesse momento as necessidades de modularidade, facilidades de
manuteno e atualizao e principalmente um curto tempo de desenvolvimento, levaram o
sistema a se reestruturar e incorporar o mximo de elementos em software, alm de nos
direcionar a utilizar, sempre que possvel, elementos hardware off-the-shelf.
Para a reestruturao desse mdulo de simulao, utilizamos o conceito de
instrumentao virtual, onde cada instrumento um co-projeto hardware-software que pode
agregar vrias funes distintas. A deciso sobre o que deve ser implementado em hardware
e software, visa um aproveitamento mximo das vantagens de cada uma destas abordagens
e j deve considerar um computador pessoal como plataforma.
No cabe aqui discutir se esse um fato positivo ou negativo, mas a realidade que
essa deciso nos ser de certa maneira imposta pelos fabricantes de equipamentos de
instrumentao disponveis no mercado. Portanto placas de gerao e aquisio de sinais
(DAQ boards) realizam as funes de interface com o mundo exterior e todo o processamento
feito ao nvel de software. Dessa forma, uma mesma configurao de hardware pode ser
compartilhada por vrios instrumentos, cujos desempenhos melhoram automaticamente,
medida que a plataforma atualizada. O instrumento tambm se beneficia do
desenvolvimento de novos sistemas operacionais, arquiteturas cliente-servidor, tecnologias
de conectividade com alcance mundial como a Internet e de compartilhamento de dados
como OPC (OLE for Process Control) [16].
- 25 -
- 26 -
4.1 Definio de Plataformas de Hardware e Software
A escolha da plataforma de software ocorreu paralelamente definio do hardware.
Isso implicou que a plataforma fornecesse drivers para as placas escolhidas, facilitando ao
mximo a comunicao entre ambos. J neste primeiro aspecto, os softwares LabVIEW e
LabWindows/CVI se mostraram a opo mais adequada, visto que eles possuem a mais
vasta biblioteca de drivers para DAQs, dos mais diversos fabricantes. Outros ambientes
avaliados que no atenderam aos requisitos do sistema foram: ADAC TestPoint e HP VEE,
por no possurem os drivers para DAQs necessrios. Compiladores C++ em geral
demandariam um enorme tempo de desenvolvimento e grandes esforos para futuras
atualizaes. O mesmo vale para ambientes como Delphi e Visual Basic. Como ambos so
funcionalmente equivalentes e possuem um compilador que gera programas executveis, a
escolha final foi pelo LabView, unicamente por ser um ambiente de programao grfica com
alguns conceitos de orientao a objeto, que propiciaria uma maior facilidade para
atualizaes futuras e reduziria substancialmente o tempo de desenvolvimento do sistema.
Para garantir total compatibilidade entre o software e o hardware e pela comprovada
qualidade, optamos por placas DAQ fabricadas tambm pela National Instruments. As
placas deveriam possuir diversos canais analgicos de entrada e de sada, com taxas de
amostragem da ordem de 100KS/s, linhas digitais de entrada e sada e
contadores/temporizadores. As placas escolhidas para satisfazer essas necessidades foram:
AT-AI-16XE-10
- 16 canais de entrada analgica single-ended ou 8 diferenciais, c/resoluo de
16 bits a uma taxa de amostragem de 100KS/s
- 8 linhas TTL de E/S
- 2 contadores/temporizadores de 24 bits c/ freqncia mxima de 20MHz
AT-AO-6 e AT-AO-10
- 6 ou 10 canais de sada analgica, c/ resoluo de 12 bits e uma taxa de
atualizao mxima de 300KS/s, unipolares ou bipolares
- 8 linhas TTL de E/S
Para a validao do projeto, o simulador foi desenvolvido em uma verso de bancada,
e somente numa segunda etapa ele ser implementado em um laptop. Essa atualizao j foi
levada em conta durante a elaborao do software, garantindo um esforo mnimo de
desenvolvimento para implement-la. A plataforma de hardware atual um IBM PC, com
processador de 100MHz e 64MB de RAM. O gabinete IBM se mostrou fundamental para esta
implementao, pois foi o nico no qual pudemos alocar 3 placas ISA com mais de 30 cm
cada! Esse problema no ocorrer na verso laptop, no entanto necessitaremos de vrios
slots PCMCIA tipo II e atualizao rpida de vdeo, o que limitar a escolha do modelo
apropriado.
Aps essas definies, passemos a uma reviso da organizao do sistema em relao
abordagem com o mdulo de simulao descrita na Figura 9 acima. Com a utilizao de
placas DAQ fabricadas, estamos incorporando o mdulo de simulao fsica e logicamente ao
PC, com a garantia extra de estarmos lidando com componentes eletrnicos de alta preciso
e com desempenho j bem caracterizado e de eficincia comprovada.
- 27 -
O bloco Gerao e Aquisio de Sinais implementado atravs dos canais
analgicos de entrada e sada, contadores/temporizadores e linhas TTL das placas. Os
blocos de software MAIN e Rotinas de Simulao passam a ser armazenados na mesma
mdia (hard-disk), executados pelo mesmo processador (Pentium 100) e implementados na
mesma linguagem de alto nvel (LabVIEW 4.1) utilizada para o banco de dados de
centralinas, eliminando a necessidade dos blocos Serial RS-232, Gerenciador de
Comunicao, Tratamento de Pacote, Buffer de Dados e Inicializao. A rea de Dados
e Variveis passa a ser a prpria RAM do PC. A interface entre as placas e o software o
barramento ISA do PC (PCMCIA na verso laptop) e a comunicao gerenciada pelos
drivers fornecidos pelo fabricante.
Para completar a descrio do processo Sntese de Hardware, nos falta ainda a
circuitaria de condicionamento dos sinais de entrada e sada para os nveis de tenso e
corrente adequados s placas DAQ e as cargas automotivas esperadas pela centralina.
Apesar de tambm haverem diversos tipos de equipamentos fabricados pela National
Instruments para o condicionamento de sinais e at para a simulao de alguns tipos de
cargas, decidimos realizar o desenvolvimento de um mdulo de condicionamento de sinais
especfico para nosso sistema.
O problema que a centralina possui diversas funes de auto-diagnose e adaptao
a situaes de falha de um ou mais componentes. Como cargas indutivas como os bicos
injetores e as bobinas de ignio no seriam simulveis de forma satisfatria, correramos o
risco de falsear os resultados da simulao e por isso decidimos embutir cargas reais no
mencionado mdulo de condicionamento de sinais. Esse mdulo possui um conector para
cada placa (os cabos so fornecidos pelo fabricante) e um conector para a centralina, cujo
chicote deve ser construdo pelo usurio para cada modelo de centralina, baseado em
informaes fornecidas pelo sistema simulador. A verso de bancada est esquematizada na
Figura 10 e ser descrita em detalhes no Captulo 7.
Harness
- 28 -
Captulo 5 Modelamento
O grande desafio para o desenvolvimento de sistemas de engenharia baseados em
software tornar essa atividade um processo industrial. Por ser um ramo de atividade
relativamente novo, ao contrrio de sistemas de gerenciamento de bancos de dados e
automatizao de tarefas administrativas, ele ainda est por alcanar um nvel de
maturidade que estabelea prticas racionais j consensadas pelo mercado para seu
desenvolvimento e explorao como produtos comerciais. Sem detrimento da criatividade
como principal ferramenta do projetista, o que se busca um processo de desenvolvimento
que englobe todo o ciclo de vida do projeto, desde a especificao dos requisitos at as
atividades de manuteno e aprimoramento. A cada etapa do projeto, esse processo deve
gerar resultados palpveis e independentes do indivduo que o execute, portanto qualquer
pessoa qualificada para uma operao deve ser capaz de execut-la de forma similar;
permitindo a alocao de tarefas para vrios grupos at mesmo subcontratados; fazendo uso
(e reuso) de blocos de construo e componentes predefinidos e com a possibilidade de
planejar e calcular o processo com grande preciso.
O desenvolvimento de um sistema pode ser visto como um processo de produo de
descries que o modelam. At mesmo o cdigo fonte da verso final um modelo que pode
ser compreendido pelos programadores e pelo compilador. Essas descries so feitas
atravs de modelos com um detalhamento que vai sendo includo progressivamente,
medida que os modelos se tornam mais formais e incorporam mais estrutura e menos
abstrao ao sistema.
Sendo o avano tecnolgico inevitvel, torna-se de capital importncia prevermos o
fator obsolescncia e obtermos o mximo de vida til para o sistema. A nica maneira de
garantir essa premissa, seria a utilizao de uma abordagem que possua as caractersticas
descritas acima intrinsecamente, e tais abordagens so necessariamente orientadas a objeto.
Aps a avaliao de diversos mtodos como: Object Modelling Technique (OMT)[17], Fusion[18]
e Object-Oriented System Analysis (OOSE) [19]; optamos por uma variante deste ltimo
conhecida como Objectory[19].
O primeiro modelo do Objectory o modelo de requisitos, que identifica os use cases.
A partir dele, iremos desenvolver os outros modelos de forma incremental e realimentada at
chegarmos ao modelo de implementao, que corresponde ao prprio sistema desejado. Esse
desenvolvimento incremental porque as particularidades do sistema que dependem do
ambiente de desenvolvimento especfico devem ser inseridas gradualmente, gerando modelos
cada vez mais detalhados. Isso garante uma base slida e quase imune a mudanas, pois o
sistema deve prescindir do ambiente como especificado nos requisitos. E realimentado
porque medida que avanamos, encontramos inconsistncias que devem ser resolvidas ou
alterando-se um pouco a estrutura do modelo problemtico, ou voltando atrs e
remodelando o comportamento inconsistente em modelos anteriores. A deciso sobre qual
alterao a ser feita deve considerar a manuteno da rastreabilidade entre os modelos com
a independncia do ambiente em modelos anteriores.
- 29 -
Tambm importante salientar que um modelamento orientado a objeto no implica
necessariamente no uso de uma linguagem orientada a objeto. Aqui precisamos deixar claro
alguns pontos:
o LabVIEW em sua verso 4.1 no suporta diretamente programao
orientada a objetos
o LabVIEW s permite a declarao explcita de classes a partir da verso 6.0
As ferramentas para UML disponveis no possuem gerao automtica de
cdigo para LabVIEW
Mesmo assim consideramos que a linguagem de programao grfica LabView 4.1 era
a escolha adequada e consideramos possvel e importante tentar incorporar as principais
caractersticas de orientao a objeto em nosso sistema como: encapsulamento de dados e
funes em objetos; abstrao e polimorfismo. Obviamente a transio dos modelos para o
cdigo fonte ser muito mais dificl, mas muitos comportamentos podem ser emulados e
outros aproximados, como veremos no tem 5.6.
Para a representao dos diversos modelos do Objectory utilizamos a UML Unified
Modelling Language em sua verso 1.1[20]. Essa linguagem representa um esforo conjunto
de diversas empresas e organizaes liderado pelos renomados metodologistas Grady
Booch, Ivar Jacobson e Jim Rumbaugh atravs de sua empresa Rational Software em
padronizar as diversas representaes utilizadas em mtodos de desenvolvimento de
software, aproveitando as vantagens apresentadas por cada um deles e sofrendo atualizaes
medida que novas idias vo surgindo. A elaborao dos modelos foi feita com a
ferramenta CASE (Computer Aided Software Engineering) Rational Rose em sua verso
Demo. Infelizmente essa verso da ferramenta permite apenas um nmero limitado de
entidades por projeto (30 classes e atores, 10 usos de caso, 10 estados) e os modelos gerados
no puderam ser totalmente integrados atravs dela. Como no iramos necessitar das
funes de gerao automtica de cdigo porque nosso sistema seria implementado de
qualquer forma em LabVIEW, essa limitao foi contornvel.
Desde o incio deste trabalho em 1998, a UML continuou sendo aperfeioada e hoje
est na verso 2.0 sendo amplamente utilizada em quase todos os segmentos da indstria,
inclusive no desenvolvimento do software das prprias unidades eletrnicas a serem
testadas por este sistema. Essa aceitao s foi possvel porque a UML o resultado de um
fenomenal trabalho que uniu os maiores especialistas acadmicos em programao
orientada a objeto junto com indstria. Em nossa opinio, isso demonstra que a escolha foi
mais que acertada. A Figura 11 abaixo mostra o processo de desenvolvimento da UML e a
Figura 12 mostra a origem das mais importantes contribuies nesse processo.
- 30 -
Figura 11: Desenvolvimento da linguagem UML
- 31 -
- 32 -
5.1 Modelo de Requisitos Diagramas de Use Cases
O primeiro modelo a ser criado para o nosso sistema o Modelo de Requisitos. Esse
modelo deve representar a funcionalidade do sistema sob o ponto de vista do usurio. Ele
parte de um documento de requisitos, que nada mais do que uma descrio textual do
comportamento esperado e das funes executadas pelo sistema, com o auxlio de figuras
onde houver necessidade; e mais importante, elaborado em conjunto entre seus projetistas e
usurios. Nosso documento de requisitos j foi descrito resumidamente no Captulo 3, na
seo Elaborao das Especificaes. Esse modelo comea com a identificao dos atores
onde estes representam os papis que um usurio pode ter perante o sistema e no uma
pessoa em particular que ir interagir com ele.
O segundo passo consiste em identificar os use cases possveis para cada ator. Cada
use case deve representar uma tarefa a ser executada pelo sistema, a fim de satisfazer o
conjunto de tarefas que caracteriza o papel de cada ator. O conjunto dos use cases para
esses atores deve representar toda a funcionalidade disponvel no sistema. Gostaramos de
enfatizar o carter modular desse mtodo, salientando que novas funcionalidades podem ser
acrescentadas ao sistema incluindo-se novos use cases no modelo atual, sem alterar em
nada sua essncia e reaproveitando comportamentos semelhantes. Somente aps todos os
use cases estarem identificados, buscaremos estabelecer relaes de herana entre os
atores, procurando aqueles que possam exercer todas as funes de um outro e mais
alguma(s). Para a centralina, foram identificados 5 atores, que podem ser vistos na Figura 13
abaixo com suas relaes de herana e seus respectivos casos de uso.
- 33 -
Figura 14: Atores e casos de uso relevantes para nosso sistema
- 34 -
5.2 Modelo de Objetos do Domnio do Problema Diagrama de Classes
O prximo modelo a ser criado o Modelo de Objetos do Domnio do Problema,
descrito principalmente atravs de Diagramas de Classes. Esse modelo deve representar a
estrutura e sub-estrutura do sistema atravs de classes, atributos, operaes ou mtodos e
associaes. Estudando-se os use cases deve-se identificar toda referncia a possveis
entidades que contenham informaes geradas pelo ou necessrias para o sistema, bem
como entidades que executem tarefas. Em seguida, devem ser identificadas relaes de
dependncia entre essas entidades por interpretao do texto dos use cases. Obviamente
esta uma tarefa iterativa, onde a interpretao abstrada do texto deve ser continuamente
verificada com os clientes e futuros usurios do sistema para verificar se ela correta e
atende as especificaes dadas. As entidades identificadas so chamadas de Classes e sua
definio bem como a definio das relaes de interdependncia entre elas a etapa mais
crtica de todo desenvolvimento de sistema orientado a objeto. No iremos descrever aqui as
discusses interminveis durante essa etapa do projeto, neste ponto infelizmente com pouco
apoio da parte mais interessada nosso patrocinador , mas iremos descrever os pontos
principais da soluo proposta.
Da anlise dos use cases apresentados no Apndice A, identificamos rapidamente
Classes como base de dados, teste, produto, componente, rea de transferncia e muitas
outras. Para exemplificar, do Modelo de Requisitos temos que a base de dados composta de
produtos, componentes e testes. Um Produto composto por diversos componentes
associados a um padro de pinagem e um painel frontal e capaz de executar um ou mais
testes. A relao entre essas principais classes do sistema pode ser vista na Figura 16.
- 35 -
Obviamente esse nico diagrama acima no suficiente para descrever toda a
estrutura do sistema. Estudando os requisitos apresentados no Captulo 3 e os tipos de
sensores e atuadores com os quais as centralinas esto conectadas, pudemos classificar
esses componentes em nove grupos distintos, conforme sua funo para a centralina e a
forma como seus respectivos sinais gerados/adquiridos sero tratados pelo simulador. Esse
detalhamento das classes Produto e Componente pode ser visto na Figura 17 abaixo.
Propriedades comuns a todos os tipos de componente como Tipo e Modelo pertencem
classe genrica Componente e cada um dos distintos tipos possui suas propriedades
especficas como Tabela de Valores ou Valor Mximo. Por fim, a Figura 18 na prxima
pgina mostra mais algumas classes importantes para o sistema
- 36 -
Figura 18: Outras classes importantes
- 37 -
- 38 -
5.3 Modelo Dinmico Diagramas de Objetos
Como pudemos observar, os diagramas de classes representam a estrutura esttica
do sistema, quais os tipos de informao a serem manejados e como eles esto associados,
mas no tm nenhuma informao quanto ao momento em que cada tipo de informao
dever ser utilizado. Os diagramas de classes so atemporais.
Para representar o comportamento interno do sistema, utilizamos o Modelo
Dinmico. Esse modelo se compe de distintos tipos de diagramas, tantos quantos se faam
necessrios para conseguir abranger os diversos pontos de vista necessrios para
possibilitar uma anlise detalhada do sistema. Ao contrrio dos diagramas de classes que
representam todas as possibilidades do sistema de uma s vez (independente se essa
possibilidade est ou no sendo utilizada), utilizaremos agora Diagramas de Objetos, que
mostram uma foto do sistema em um determinado instante e sob um determinado foco. Os
elementos desses diagramas so objetos, links e mensagens as instncias (realizaes
em tempo de execuo) de classes, associaes e solicitaes de execuo de mtodos.
Os principais tipos de diagramas de objetos so os Diagramas de Colaborao (foco
na troca de mensagens entre objetos) e os Diagramas de Seqncias (foco na interao entre
objetos). Nas Figuras 19 e 20 a seguir mostramos exemplos de diagramas de colaborao
iniciados por um objeto e por um usurio do sistema.
- 39 -
Figura 20: Exemplo de Diagrama de Colaborao iniciado por usurio
No iremos nos estender mais nesses dois diagramas no somente porque sua
representao grfica ocupa muito espao, mas principalmente por uma particularidade do
LabVIEW: por ser uma linguagem de programao grfica, o cdigo-fonte de um sistema a
desenvolvido se assemelha muito a diagramas de objetos. Ou seja, quase toda a informao
presente nos diagramas de objetos pode ser ou diretamente inferida do cdigo-fonte ou
indiretamente com ajuda dos diagramas de estado, com os quais iremos dedicar especial
ateno no Item 5.4 logo a seguir. No Captulo 6 iremos ainda examinar o cdigo-fonte das
principais sub-rotinas do sistema.
- 40 -
5.4 Modelo Dinmico Diagramas de Estados
Um diagrama de estados uma representao grfica do comportamento dinmico de
uma ou mais classes. Cada estado representa um estado de equilbrio (esttico ou dinmico)
possvel para esta classe, ou seja, um estado no representa necessariamente uma situao
de espera, mas sim uma determinada seqncia de atividades que ser executada para um
determinado contexto.
config error
4 [empty]
config error
[code, source]
Error Simulation
Do/ Show
ErrorMessage(error) Do/ PowerMonitor
key on/ StartUp
/ Simulate
error/ ShutDown
simulation error endtest/ ShutDown
[code, source] simulation error
[empty]
History
Do/ Save History
Stop
Entry/Finish
- 41 -
Neste diagrama tambm esto representadas todas as possveis transies de estado
com os respectivos eventos que condicionam essa transio. Os eventos que iniciam uma
transio podem ser tanto externos classe em questo (mensagens) como tambm
resultado de operaes internas ou at mesmo ocorrncias peridicas.
A Figura 21 na pgina anterior mostra o diagrama de estados para a classe Teste j
mencionada na Figura 17. Nessa figura podemos reconhecer estados (1), atividades a serem
executadas neste estado (2), transies (3), eventos de transio (4), mensagens (5), etc.
As atividades dentro de cada estado esto descritas de forma seqencial, porm
algumas delas so iterativas e sua concluso depende tambm do estado de outras classes.
Nestes casos, necessitamos de diagramas de sub-estados, para descrever o comportamento
dinmico dessas outras classes. A Figura 22 mostra o diagrama de sub-estados para a
atividade Simulate dentro do estado Simulation da Figura 21 anterior. Um elemento
interessante neste diagrama a ativao simultnea de diversos estados em diferentes
classes (6).
config error [empty]
Simulate Start Up
Power Monitor 6 Entry/ Update Transducer(default values)
Entry/ Show key on / Push FreqSens Buffer(default values)
UserInterface Exit/ Start AOFreqSens(continuous)
Do/ Acquire Vbatt
Interact
Do/ Acquire Vbatt
Do/ Acquire DigitalOutputs
Check Stepper Do/ Acquire PowerAct Waveform(injector
end test Do/ Check PhaseError #, ignition?)
Do/ Acquire StepperPosition Do/ Update UserInterface(Transfer Area)
error/ Show Message(error) Do/ Update TransferArea(useraction)
key off Check Power
Do/ Check EndTest&KeyOn
AIOK?:= EndTest OR KeyOff
key off
AllOK?:= EndTest OR KeyOff
- 42 -
A traduo de um diagrama de estados para cdigo de programao basicamente a
converso de um modelo direcionado a eventos para um modelo seqencial, a dificuldade
como definir a periodicidade de verificao da ocorrncia de um possvel evento que dispare
uma transio de estado sem comprometer de forma significativa a funcionalidade do
sistema. A soluo em LabVIEW utilizada por nosso sistema uma mescla de conceitos
adquiridos atravs de uma lista de discusso com outros programadores espalhados pelo
mundo com alguns toques pessoais. A Figura 23 mostra os elementos de programao
utilizados e o texto a seguir explica resumidamente a funo de cada um deles:
1) Estrutura While define os limites do diagrama de estados em questo. O cdigo
em seu interior ser ciclicamente executado at que ocorra a condio de parada.
2) Constante de tipo enum define o estado inicial para esse diagrama.
3) Condio de parada define o estado final para esse diagrama de estados, aps o
qual a execuo dever ser terminada. Neste exemplo todas as atividades como fechamento
de arquivos, trmino de acesso a bancos de dados, etc. devero ser realizadas no Estado 4.
4) Estrutura Case define os limites de cada estado. Dentro de suas fronteiras est
o cdigo a ser executado para um determinado estado. Em sua essncia, uma estrutura
Case aceita valores numricos, mas atravs da definio de tipo enum podemos traduzir
essa informao numrica nos nomes dos possveis estados. S possvel visualizar um
estado de cada vez, neste exemplo vemos o cdigo correspondente ao Estado 1. Usando as
flechinhas ao lado do nome do estado atual podemos chavear para os trechos de cdigo
correspondentes aos demais estados.
5) Contador define o tempo mnimo de execuo do estado, para garantir que
quando uma classe estiver em um estado onde poucas atividades so executadas, ela no
consuma recursos do sistema desnecessariamente em verificaes de eventos.
6) As atividades em si a serem executadas nesse estado.
7) Verificao de evento de transio dependendo da ocorrncia ou no de evento,
define se a classe de permanecer no estado atual ou mudar para algum outro.
8) Registro de deslocamento recebe um valor da verificao de evento no final de um
ciclo de execuo e o disponibiliza para o prximo ciclo. Neste caso ele recebe o prximo
estado a ser executado (eventualmente o mesmo atual) e esse valor utilizado para controlar
a estrutura Case e definir qual trecho de cdigo dever ser executado a seguir.
9) Estrutura Se uma estrutura auxiliar opcional, usada em estados cujas
atividades devem ser executadas apenas uma vez e depois a classe permanece esperando a
ocorrncia de um evento de transio. Atravs da comparao entre o ltimo estado
executado (valor do registro de deslocamento no ciclo t-2) e o novo estado requerido (valor do
registro de deslocamento no ciclo t-1), pode-se evitar a execuo de um trecho de cdigo.
- 43 -
1
6 6
7
6 8
8
- 44 -
5.5 Modelo Fsico Diagramas de Componentes e de Implantao
H dois tipos de diagramas que modelam a implementao fsica do sistema:
o diagrama de componentes mostra a organizao entre pacotes de cdigo (arquivos
de cdigo fonte, bibliotecas, tabelas de banco de dados, etc.). A relao mais usada
a dependncia, mostrando como um arquivo de cdigo fonte depende de um outro
que ele inclui ou como um executvel depende de uma biblioteca (juno em tempo
de compilao, conexo ou execuo), mas tambm podem ser utilizadas relaes de
generalizao, associao e realizao. Os elementos de modelagem so os
componentes e as interfaces. A UML reconhece cinco esteretipos de componentes:
Executvel; Biblioteca; Tabela; Documento e Arquivo.
o diagrama de implantao mostra a estrutura da aplicao e a configurao dos ns
de processamento em tempo de execuo. Utilizado principalmente para sistemas
embarcados, distribudos ou cliente/servidor, pois permite avaliar conseqncias da
distribuio e alocao de recursos.
Na Figura 24 podemos ver o diagrama de componentes completo para o nosso
sistema simulador e na Figura 25 o diagrama de implantao com os principais blocos de
software que so ativados em tempo de execuo.
Security users.id
Access Control
Data Access
Database
Management
Database (Products
Data Access
& Components)
EditINI
Simulation
User
AutoSEFI.ini Interface
Database
(Controls)
Figura 24: Diagrama de Componentes
- 45 -
LogIN
users.id
UserID
CadProd ProdEdit
Engine
PartSEL
Cadastro
About Database (Products
& Components)
RunTest GetPars
- 46 -
5.6 Resumo da Aplicao da UML com LabVIEW 4.1
Antes de tudo, precisamos esclarecer que a programao em LabView feita em duas
vistas complementares: a janela de diagrama (cdigo a ser executado) e a janela de painel
frontal (interface grfica com o usurio). Para cada controle ou mostrador posicionado no
painel frontal gerado um elemento de conexo na janela de diagrama para que ele possa
ser utilizado (conectado) no resto do cdigo.
Cada arquivo ou sub-rotina chamado de VI (virtual instrument), VIs podem ser
gravados como arquivos individuais com a extenso .vi ou agrupados em arquivos de
bibliotecas com extenso .llb. Esses arquivos funcionam como se fossem sub-diretrios,
porm seu contedo s pode ser acessado pelo LabView. Com essas informaes bsicas,
podemos seguir em frente.
- 47 -
J em LabVIEW, precisamos sempre de um controle/mostrador posicionado no
painel frontal para poder utiliz-lo no cdigo. A abordagem mais direta seria considerar
como declarao de classe um conector/mostrador copiado da nossa biblioteca e o
instanciamento aconteceria quando esse conector/mostrador recebia algum valor concreto.
A desvantagem bvia que no caso de se atualizar a definio de classe teramos que buscar
por todo o cdigo aonde cada uma delas foi usada.
Uma oura abordagem que usamos em alguns casos foi criar um VI com diversas
declaraes de classe. Depois fazamos chamadas a esse VI solicitando como resposta uma
das declaraes de classe disponveis, assim atualizaes eram feitas apenas em um lugar.
- 48 -
Captulo 6 Realizao do Software
A programao em LabView feita em duas vistas complementares: a janela de
diagrama (cdigo a ser executado) e a janela de painel frontal (interface grfica com o
usurio).
Cada arquivo ou sub-rotina chamado de VI (virtual instrument), VIs podem ser
gravados como arquivos individuais com a extenso .vi ou agrupados em arquivos de
bibliotecas com extenso .llb. Esses arquivos funcionam como se fossem sub-diretrios,
porm seu contedo s pode ser acessado pelo LabView.
Durante o desenvolvimento, o sistema simulador era composto dos seguintes
arquivos em um diretrio-base: autosefi.ini (basicamente um arquivo texto, contendo
parmetros de inicializao do sistema), Corefiles.llb, DataBaseManagement.llb, Security.llb,
Simulation.llb, UserInterface.llb e Users.id (arquivo criptografado em formato proprietrio
que desenvolvemos, contendo toda a base de dados dos usurios cadastrados no sistema).
Para a verso de distribuio, o arquivo CoreFiles.llb foi compilado gerando o AutoSEFI.exe e
as llbs foram salvas com a opo Application Distribution, ou seja, os VIs no contm os
diagramas. Complementando a organizao do sistema, neste diretrio-base existem os
seguintes sub-diretrios: Controls e DataBases. Uma listagem dos VIs em cada biblioteca .llb
pode ser encontrada no Apndice B.
O sub-diretrio DataBases contm as bases de dados que nada mais so do que
arquivos com as extenses .cmp e .pdt (formato proprietrio desenvolvido no escopo deste
projeto) contendo as informaes de configurao dos Componentes e Produtos
respectivamente, organizados em estruturas de sub-diretrios conforme o esquema da base
de dados Example na pgina seguinte.
O sub-diretrio Controls contm arquivos de extenso .ctl (formato proprietrio do
LabView) com os seguintes controles usados nos diversos painis frontais do sistema
simulador: actuatori.ctl, actuatorii.ctl, configinfo.ctl, ecu.ctl, ECU1.ctl, idlespeed.ctl,
mainstates.ctl, sensori.ctl, sensorii.ctl, type.ctl.
De forma anloga ao modelamento, iremos descrever nosso sistema comeando pelo
ponto de vista do usurio.
- 49 -
DataBases
Example
Ignition Cannister Stepper MAP S_O2 T_Air T_H2O Throttle Knock RPM_4+1 Speed
- 50 -
6.1 Descrio da forma de utilizao do Sistema
Instalao
Infelizmente no foi gerada uma verso de distribuio utilizando a interface de
instalao padro Windows. Para transportarmos o sistema para uma outra mquina,
utilizamos basicamente um arquivo compactado (.zip) com os arquivos AutoSEFI.exe e as
outras llbs mencionadas acima. As estruturas de diretrios para a Base de Dados e os
Controles ainda precisavam ser criadas manualmente dentro do diretrio escolhido para
descompactar os arquivos do sistema.
No Captulo 9 mencionaremos uma maior facilidade de instalao do sistema
simulador como requisito para futuras expanses do sistema.
- 51 -
A interface do Gerenciador de Usurios est mostrada na Figura 27. A caixa da
esquerda mostra os usurios atualmente registrados no sistema, sendo que o administrador
o que possui o smbolo ao seu lado. O formulrio de registro direita mostra os
atributos do usurio selecionado. O administrador pode modificar, adicionar e remover
usurios, desde que no haja repetio de logins. Os privilgios de utilizao do sistema
seguem o modelamento j discutido, e so definidos com base no(s) ator(es) escolhido(s) para
cada usurio dentre:
Tcnico: s capaz de executar testes em produtos;
Engenheiro: alm de executar testes, tambm capaz de configurar produtos e
componentes;
Gerente: s capaz de analisar relatrios de testes armazenados na Base de
Dados.
Identificao do Usurio
Ao executar o arquivo AutoSEFI.exe o usurio apresentado tela mostrada na
Figura 28 abaixo, onde deve informar seu login e senha de acesso.
- 52 -
Engine
Aps informar seu login, o usurio apresentado tela principal do sistema onde
pode escolher que tipo de atividade deseja executar com o sistema. Apenas as atividades
para as quais seu perfil est autorizado podem ser selecionadas.
- 53 -
Figura 31: Cadastro de Componentes
O primeiro passo selecionar o Tipo de Componente dentre os cinco disponveis no
sistema: Transdutores, Sensores de Freqncia, Atuadores de Potncia, Atuadores de
Freqncia e Atuadores de Marcha Lenta. A caixa abaixo do seletor mostra sempre os
atributos pertinentes ao Tipo de Componente selecionado. Ao confirmar a seleo,
apresentada a janela de Seleo de Pea, onde so oferecidas as opes de adicionar,
modificar ou remover um Componente do tipo previamente selecionado.
Esta janela, mostrada na Figura 32 na pgina seguinte, utilizada para navegao
na Base de Dados, somente entre componentes do tipo anteriormente selecionado. A lista da
esquerda navega entre grupos de componentes, atravs de duplo-clique no nome do grupo
para descer um nvel ou em .. para voltar para o grupo anterior (nvel acima). A lista da
direita mostra os componentes disponveis para serem selecionados dentro do grupo
selecionado esquerda.
Importante: Os sub-grupos no so mostrados na lista da direita. O usurio deve
selecionar um grupo para poder ver seus sub-grupos na lista da esquerda.
Pressionando New, o usurio solicitado a informar um nome para o novo
componente ou grupo a ser criado, como pode ser visto na Figura 33.
- 54 -
Figura 32: Seleo de Pea
Transducer:
(ring) Sensor Type: Indicates the kind of transducer for this component. It is used by the system to organize the
Database.
(string) Model: The name to serve as a reference for the component in the Database.
(dbl) Maximum Value: The maximum value (in Volts) this signal can assume.
- 55 -
(array) Values Table: A look-up table with the conversion of physical to voltage unities for this component. The
first column represents the physical values, and the second the voltages.
(string) Transfer Function: The transfer function that fits better the points in the Values Table. This information
is not being used in the current version.
Frequency Actuator:
(ring) Sensor Type: Indicates the kind of frequency actuator for this component. It is used by the system to
organize the Database.
(string) Model: The name to serve as a reference for the component in the Database.
(dbl) Maximum Value: The maximum value (in Volts) this signal can assume.
(string) Amplitude Function: The transfer function relating the amplitude with the frequency of the signal. This
information is not being used in the current version.
Power Actuator:
(ring) Actuator Type: Indicates the kind of power actuator for this component. It is used by the system to
organize the Database.
(string) Model: The name to serve as a reference for the component in the Database.
(dbl) Opening/Rise Time (usec): Time spent to open the injector or time to charge the ignition coil.
(dbl) Closing/Spark Time (usec): Time spent to close the injector or duration time of the spark produced by the
ignition coil.
Frequency Actuator:
(ring) Actuator Type: Indicates the kind of frequency actuator for this component. It is used by the system to
organize the Database.
(string) Model: The name to serve as a reference for the component in the Database.
(dbl) Operating Frequency: The operating frequency for the duty cycle of the component. The first column
represents the physical values, and the second the duty cycles in percentages.
(array) Values Table: A look-up table with the conversion of physical to duty cycle unities for this component.
- 56 -
Finalmente, muitos transdutores como NTCs, PTCs, etc. representam variaes em
uma grandeza fsica atravs de variaes em sua resistncia. Em dispositivos de eletrnica
automotiva, a circuitaria de entrada desses transdutores usualmente consiste de um resistor
de pull-up ligado a uma tenso Vcc, e o divisor resistivo entre o transdutor e este resistor
fornece um nvel de tenso que interpretado pelo dispositivo. Como nossas placas DAQ so
adequadas para a gerao de nveis de tenso e no resistncias, o Engenheiro pode fornecer
os valores de resistncia disponveis com o transdutor e os valores do resistor de pull-up e da
tenso Vcc para que o mtodo Extend VT calcule os valores apropriados.
- 57 -
Gerenciador de Produtos
Depois que um Engenheiro j cadastrou Componentes na Base de Dados, ele pode
configurar um produto. O Gerenciador de Produtos o mdulo atravs do qual um
Engenheiro pode adicionar, modificar ou remover produtos da Base de Dados.
O primeiro passo selecionar o tipo de produto. Nesta verso atual o nosso sistema
como um todo suporta apenas centralinas, mas a interface inicial de seleo que pode ser
vista na Figura 35 abaixo j mostra os atributos e mtodos associados a outros tipos de
produtos medida que o seletor de produto acionado.
- 58 -
Da mesma forma que com o Gerenciador de Componentes, o sistema apresenta a
mesma janela de Seleo de Pea mostrada na Figura 32. A funcionalidade anloga
descrita anteriormente, com a diferena que os campos na Figura 35, agora com o boto
Modify substituindo o boto Ok, no sero preenchidos manualmente. O Gerenciador de
Produtos tem uma ferramenta prpria para permitir uma viso melhor dos componentes que
esto sendo associados ao produto em questo. Esta ferramenta ativada ao se pressionar o
boto Modify e sua janela, com os componentes associados ao grupo Transdutores, pode
ser vista na. Figura 36.
- 59 -
O sistema vai alocando os recursos disponveis em seu mdulo de condicionamento
de sinais medida que o Engenheiro vai associando esses componentes aos pinos do
Produto. Essa tabela de alocao d origem ao relatrio de conexes para o chicote que unir
o Produto ao Mdulo de Condicionamento.
Segue-se um resumo dos atributos disponveis para cada o Tipo de Produto ECU
(centralina). A listagem est em ingls, pois faz parte da documentao original do sistema.
ECU:
(string) Model: The name to serve as a reference for the component in the Database.
(array) Transducers: Array of strings containing the relative paths of all transducers associated with this
product.
(array) Frequency Sensors: Array of strings containing the relative paths of all frequency sensors associated with
this product.
(array) Power Actuators: Array of strings containing the relative paths of all power actuators associated with this
product.
(array) Frequency Actuators: Array of strings containing the relative paths of all frequency actuators associated
with this product.
(string) Idle Speed Actuator: Contains the relative path of the idle speed actuator associated with this product.
(string) Associated Panel: Contains the relative path of the user interface panel associated with this product.
- 60 -
Com o boto Hold Output pressionado, o Tcnico pode alterar os valores de vrios
sinais sem alterar o ambiente que est sendo simulado. Estes s sero atualizados
simultaneamente quando o boto for liberado.
O boto Run Script permite que o Tcnico execute um script dentre os disponveis
na Base de Dados, e, portanto previamente cadastrado por um Engenheiro. Scripts so
cenrios dinmicos que representam todos os valores a serem assumidos pelos sinais de
entrada da centralina e um limite esperado para seus sinais de sada, ao longo do tempo. O
Engenheiro pode cadastrar uma seqncia de sinais variando-os a seu gosto ou converter os
dados adquiridos de um veculo em um percurso real, simulando esse percurso
dinamicamente para a UUT (Unity Under Test).
A estratgia de teste closed-loop no pode ser implementada devido total
inexistncia de dados sobre o comportamento dinmico de um veculo. Para futuras
implementaes desta modalidade de teste, dependeremos fundamentalmente de maior
colaborao da Magneti Marelli e integrao com a equipe desenvolvedora do sistema.
O painel frontal da centralina modelo 1AVB76AT pode ser visto na Figura 37 a seguir.
- 61 -
Figura 37: Painel Frontal da Centralina 1AVB76AT
- 62 -
Documentao
A documentao dos resultados de um teste um aspecto muito importante do
processo de verificao. A habilidade de gravar e analisar a operao do software de controle
da ECU para estmulos externos conhecidos facilita a verificao do software e do sistema. O
nvel de documentao ser dependente dos requisitos do sistema em particular e
geralmente recaem em uma de trs categorias: inspeo visual, traados grficos ou
listagens numricas. Procedimentos de teste que requerem apenas uma confirmao do
funcionamento ou no da ECU recaem na primeira categoria. Na segunda categoria, os
traados grficos so a principal ferramenta de documentao utilizada para demonstrar a
conformidade do software da ECU com os requisitos do sistema, pois fornecem uma
descrio precisa das operaes internas da ECU e do ambiente externo atravs da
sincronizao temporal de todos os fluxos de dados. Na terceira categoria as informaes
grficas podem ser convertidas em listagens numricas para anlise mais aprofundada dos
valores.
O simulador foi desenvolvido com a capacidade de gerar documentao nas trs
formas descritas acima, no entanto as caractersticas de cada documentao no foram
especificadas pela Magneti Marelli. Apenas para efeito de validao do nosso sistema, foram
feitos alguns testes com a gerao de arquivos contendo dados time-stamped, cujas rotinas
no foram incorporadas na verso atual do software.
- 63 -
- 64 -
6.2 Descrio do cdigo-fonte
Como o LabVIEW um ambiente de programao visual, ou seja, no h cdigo
digitado mas sim desenhado, descreveremos alguns dos blocos de Software mais
importantes com auxlio de screen shots das janelas de diagrama de cada VI.
Desde j nos desculpamos pelo fato que as figuras a seguir sero em geral ilegveis.
Infelizmente este trabalho escrito no permite a utilizao de recursos como barras de
rolagem e por ser um cdigo desenhado, alguns dos blocos de Software s seriam legveis
em formato impresso com a utilizao de papel tamanho A1 ou A0. Para contornar esse
problema, disponibilizamos junto com essa dissertao todo o cdigo-fonte gravado em CD.
Recomendamos que o leitor acompanhe esse Captulo visualizando simultaneamente o
cdigo-fonte em seu computador.
No nosso primeiro exemplo vamos estudar o cdigo do Partsel.vi, responsvel pela
janela de seleo de pea e navegao pela Base de Dados j vista na Figura 32. Ele mostra
que a nossa preocupao com a documentao foi grande principalmente nos blocos de
Software responsveis pelo gerenciamento da Base de Dados. A incluso de comentrios em
um cdigo LabVIEW (o equivalente ao smbolo ' em Visual Basic ou /* ... */ ou // em C)
feita atravs de caixas de texto explicando cada trecho do cdigo, como pode ser verificado
nas Figuras 38 e 39 na pgina a seguir. Os textos em vermelho includos nessas figuras so
apenas ampliaes dos textos originais para que estes fiquem legveis, somente por esta
razo preferimos mantermo-los em ingls.
Aps este primeiro exemplo, nos concentraremos na anlise do cdigo vinculado s
atividades de simulao que no est to bem comentado como o relacionado Base de
Dados.
- 65 -
Change the current path only if an
item from directory list is double-
With Operations? (T) clicked. A double-click on the .. item
Database Base Path cannot change the path to an upper
Refresh directory list only
if the current path has level than the base path.
changed
- 66 -
Passando agora ao cdigo relacionado com a simulao, comecemos com o
Runtest.vi. Esse VI implementa o diagrama de estados mostrado anteriormente na Figura
21. Podemos ver os estados Initialization e Configuration nas Figuras 40 e 41 a seguir.
Inicializao de variveis
Os parmetros da pea
selecionada devolvidos pelo
GetPars.vi so usados para Cada recurso das placas
O path da ECU selecionada configurar os recursos das DAQ inicializado recebeu
usado para chamar o placas DAQ e o painel frontal. um task ID. Esses valores
GetPars.vi que ser visto na so passados para os
Figura 42. prximos estados.
- 67 -
Como vimos acima, o estado Configuration chama a execuo de GetPars.vi
enviando como parmetro o path da ECU selecionada. Vejamos abaixo como ele busca na
Base de Dados as informaes de cada um dos componentes associados ela.
O VI Products1.vi fornece um O VI Compnnts.vi fornece clusters vazios para inicializao de variveis com
cluster vazio para inicializao os tipos de dado que devem ser lidos, nesse caso cada um dos tipos de
de uma varivel com o tipo de Componentes que requerem uma inicializao das placas DAQ.
dado que deve ser lido, nesse
caso uma ECU.
- 68 -
Voltando ao Runtest.vi, passemos ento descrio do estado Simulation. Como
vimos no diagrama de classes da Figura 22, no devemos realizar as tarefas de aquisio,
processamento e gerao de sinais de forma seqenciada. Para compatibilizar os recursos
disponveis no nosso sistema com a velocidade de simulao requerida, o processo de
simulao foi dividido em subprocessos sendo executados de forma concorrente, cada qual
com sua prpria temporizao. Dessa forma a maioria das atividades de gerao e aquisio
foram implementadas com temporizao em hardware, com a utilizao de buffers
localizados nas prprias placas DAQ sendo a fonte/destino dos dados da simulao. A
recuperao e fornecimento dos dados de/para os buffers realizada de forma assncrona,
temporizada em software de acordo com as caractersticas dinmicas e grau de importncia
de cada tipo de sinais para o sistema. Vejamos como isso funciona na Figura 43 a seguir.
Um cluster trazendo a
informao sobre a possvel
Apenas na primeira iterao do ocorrncia de algum erro ativa Lao de cdigo para
lao de simulao executado simultaneamente diversos laos Lao de cdigo para a a gerao do sinal
o Startup.vi, que ser visto na de cdigo. interface com o usurio de RPM chamando o
Figura 44, para iniciar os chamando o Interact.vi que RPMArray_3.vi que
canais de sada analgica. ser visto na Figura 45. ser visto nas
Figuras 47 e 48.
- 69 -
Atuadores de Freqncia:
As medies necessrias para se avaliar os comandos da ECU para os atuadores de
potncia so geralmente de freqncia e/ou duty cycle. Os contadores/temporizadores
disponveis nas placas DAQ j possuem rotinas prontas para estas funes, bem como para
diversas outras de medio de tempos como durao do estado lgico alto ou baixo, etc. e
no tivemos maiores problemas com sua implementao.
Os atuadores de freqncia controlados por ECUs so geralmente vlvulas
eletromagnticas para controle de vazo de algum fluxo. Os dois principais componentes que
se encaixam nessa descrio so as vlvulas cannister e EGR. A vlvula cannister direciona
os vapores do tanque provenientes de evaporamento de combustvel para que eles sejam
consumidos no motor.
Nossa nica limitao era o fato de nossas placas DAQ possurem somente dois
contadores/temporizadores, um dos quais estava sendo utilizado para o motor de passo.
Para a verso de bancada desenvolvida e para o modelo de centralina utilizado isso no foi
empecilho, pois s tnhamos a necessidade de simular uma vlvula cannister. Esse problema
deve ser solucionado na verso final com a utilizao de outras placas DAQ, conforme ser
discutido nas concluses desse trabalho.
Como vimos, as funes de cada lao de cdigo esto encapsuladas em sub-rotinas,
principalmente para facilitar a visualizao. No caso dos atuadores de freqncia pudemos
utilizar algumas j existentes no LabVIEW sem necessidade de modificao, mas vamos
observar como funciona cada uma das demais comeando pelo Startup.vi.
- 70 -
Caso o sistema esteja em modo Power Monitoring (corresponde a chave no contato, mas
ainda no foi dada a partida), sao enviados para o painel frontal as informaes atuais de:
cannister e motor de passo (j recebidos da rea de Transferncia antes da chamada do
VI), entradas digitais e tenso de bateria (adquiridos aqui mesmo) e um array vazio
correspondente aos atuadors de potncia.
Atuadores de Potncia:
Os atuadores de potncia se dividem em dois tipos: bicos injetores e bobinas de
ignio. Em ambos os casos as informaes de interesse so obtidas atravs da monitorao
da forma de onda da corrente, sua durao e instante de ativao, sempre em relao ao
sinal do sensor de rotao.
Para garantir o melhor desempenho com nosso equipamento atual, foi estabelecido
que s seriam adquiridos os sinais do bico injetor atualmente selecionado e da bobina de
ignio. A aquisio feita em blocos de 1000 pontos para cada sinal a uma taxa de 50KS/s.
O buffer de aquisio possui 40000 posies. O instante de trigger definido por um nvel de
0,8V numa borda de subida no sinal do bico injetor e o nmero de pontos de pr-trigger
definido pelo Tcnico atravs de controle existente no painel frontal.
- 71 -
Como o tempo de abertura do bico injetor est quase sempre abaixo de 20ms, esse
o tamanho da janela de visualizao da sua forma de onda no painel frontal, no entanto o
Tcnico pode alter-lo vontade para visualizar um espao de tempo maior ou um detalhe
da forma de onda, utilizando o controle de trigger para posicionar a forma de onda na
janela de visualizao.
Para evitar paradas desnecessrias do sistema, os erros de sobre-escrita no buffer
e/ou de tentativa de leitura sem dados ainda disponveis, esto sendo ignorados e o grfico
da forma de onda simplesmente aguarda os prximos dados vlidos antes de ser atualizado.
Como as placas DAQ utilizadas no permitem a utilizao de mltiplos eventos de
trigger, a verificao dos ngulos de avano e dwell apresentou dificuldades quase que
insuperveis. Foram tentadas abordagens com a utilizao de ocorrncias (um recurso da
linguagem LabVIEW, atravs do qual utilizvamos o temporizador interno do PC) e at com a
aquisio do sinal de rotao recm-gerado junto com os sinais de corrente, para que rotinas
de software analisassem o contedo do buffer de aquisio para extrair as informaes de
temporizao. Essas alternativas foram descartadas para a verso final do sistema por serem
extremamente custosas em termos de processamento, ou imprecisas. A soluo mais
adequada ser melhor discutida na concluso desse trabalho.
Antes de passarmos para o prximo VI, queremos esclarecer que na verdade, a
gerao em si dos sinais dos sensores de freqncia acontece no Runtest.vi e pode ser vista
na Figura 43, mas como o mais importante a gerao das formas de onda que devem ser
simuladas, deixamos para explic-las aqui junto com o RPMArray_3.vi.
Sensores de Freqncia:
Os sensores de freqncia utilizados por ECUs so geralmente utilizados para
medio da rotao do motor e velocidade do veculo e deteco de detonao. A detonao
reconhecida atravs de vibraes do bloco do motor em uma determinada freqncia que
ocorrem prximo do PMS do cilindro detonante e medida com um sensor baseado
geralmente em cermicas piezoeltricas. O sinal produzido por esses sensores s analisado
nos instantes prximos a cada PMS e filtrado para que se procure apenas a freqncia
caracterstica da detonao para cada motor.
Os sensores de rotao so geralmente indutivos e detectam flutuaes no campo
magntico induzidas por dentes de uma engrenagem montada junto ao rotor em questo.
Eles podem ser de dois tipos: relutncia magntica e efeito Hall. A principal diferena entre
eles, sob um ponto de vista externo, que sensores de relutncia variam a amplitude do
sinal de sada com a rotao, enquanto que sensores Hall tm o sinal de sada com a mesma
amplitude da sua tenso de alimentao.
- 72 -
A simulao dos sinais de ambos os sensores de freqncia foi feita com canais de
sada analgica convencionais. Nesta primeira verso no foi de nosso interesse verificar os
circuitos de condicionamento de sinais internos ECU, portanto os sinais simulados sero
todos com amplitude de 5V. O sinal correspondente ao sensor de detonao ser de forma
senide na freqncia caracterstica de cada motor e o sinal do sensor de rotao obedeceu
ao respectivo quadro de sinais da centralina sendo simulada. A Figura 46 mostra o quadro
de sinais para centralinas da famlia IAW1AV.
A utilizao de canais de sada analgica trouxe conseqncias adversas que s
foram percebidas quando da implementao das rotinas de software para simular o sensor
de rotao. Os sinais gerados devem refletir quase que instantaneamente as aes do
Tcnico no painel frontal e no podem ser interrompidos para evitar funcionamento anormal
da ECU, principalmente o sinal do sensor de rotao. Isso implicou que deveramos
trabalhar com uma taxa de atualizao e um tamanho de buffer fixos devido ao longo tempo
necessrio para reconfigurar esses parmetros, durante o qual a placa no estaria gerando
nenhum sinal.
O buffer deve ser utilizado quando o sistema no consegue disponibilizar os dados a
serem gerados para a placa DAQ em tempo hbil para acompanhar a taxa de atualizao
utilizada, o que ocorre no nosso caso, pois o processo de montar matrizes de pontos
representando cada forma de onda relativamente lento. Como as placas DAQ esvaziam o
buffer bem mais rpido do que conseguimos ench-lo, devemos utilizar um buffer circular.
Pelo mesmo motivo, o buffer sempre deve conter formas de onda completas, para que elas
sejam geradas continuamente mantendo a referncia de temporizao da ECU (dente mais
longo ou dentes faltantes).
- 73 -
Roda
Fnica
60-2
Dente Dente Dente Dente Dente Dente Dente Dente
dentes
Dente Dente
Dente Dente
Dente
72
90 90
72 6 Graus 72
Roda 4
dentes
(VW)
Cilindro 1 Cilindro 3 Cilindro 4 Cilindro 2 Cilindro 1
P.M.S.
Carga da
Bobina
Injetor 1
Injetor 2
Injetor 3
Injetor 4
- 74 -
Agora, uma taxa de atualizao fixa implica em um intervalo de tempo fixo entre dois
pontos gerados. Cada valor de rotao corresponde a um intervalo de tempo no qual deve ser
gerada a forma de onda correspondente a uma volta da rvore de manivelas, de acordo com
o quadro segnali utilizado. Portanto, cada valor de rotao implica em nmero fixo de
pontos para representar a forma de onda correspondente. Finalmente, um tamanho de buffer
fixo implica em que somente algumas formas de onda so capazes de preencher totalmente o
buffer, sem sobrar ou faltar pontos. Essas formas de onda so aquelas para as quais o
tamanho do buffer mltiplo do nmero fixo de pontos que a representa!
Com essas consideraes, passamos a buscar os valores de taxa de atualizao e
tamanho de buffer que nos proporcionasse o maior nmero de formas de onda possveis de
serem geradas adequadamente. Para garantir o reconhecimento do PMS do cilindro 1,
necessitamos de uma resoluo mnima de 6 para a roda de 4 dentes. Como um ciclo da
forma de onda dessa roda equivale a 720 (2 voltas no eixo da rvore de manivelas, conforme
a Figura 46), necessitamos de no mnimo 120 pontos para represent-la. Como nossa taxa
de atualizao fixa, quanto mais pontos so utilizados para uma forma de onda mais
tempo ela leva para ser gerada, portanto corresponde a uma rotao menor. Isso significa
que os 120 pontos correspondem a duas voltas do eixo, na mxima rotao a ser simulada
pelo sistema. Considerando que a mxima rotao atingida pelos motores utilizados
atualmente em veculos particulares algo em torno de 8000 RPM, a taxa de atualizao
pode ser dada por:
RPM mx Pmn
Tat = 8000 pontos / seg
60 2
- 75 -
Pontos por Rotao Pontos por Rotao
Forma de Onda Forma de Onda
120 8333,33 350 2857,14
140 7142,86 420 2380,95
150 6666,67 525 1904,76
168 5952,38 600 1666,67
175 5714,29 700 1428,57
200 5000,00 840 1190,48
210 4761,90 1050 952,38
280 3571,43 1400 714,29
300 3333,33 ----- -----
Tabela 1: Valores Vlidos de Rotao
Dentre os possveis,
selecionado o que
mais se aproxima Se necessrio, a
ao comando do matriz j filtrada
usurio parcialmente sobre-
escrita com o padro
de detonao
- 76 -
Os clculos para a gerao das matrizes
de detonao e a que contm todas as
sequncias de pontos correspondentes a
todos os possveis valores de rotao so
feitos apenas uma vez na primeira
execuo da sub-rotina.
A matriz s filtrada
novamente se o valor
de rotao desejado for
alterado
- 77 -
O motor de passo funciona atravs da polarizao de duas bobinas posicionadas
perpendicularmente entre si com valores iguais de tenso. Invertendo a polaridade das
bobinas alternada e seqencialmente, gerado um campo magntico no estator cujo sentido
varia de +/- 45 a cada inverso de polaridade, atraindo o campo magntico do rotor. Esse
procedimento resulta num movimento do eixo em sentido horrio ou anti-horrio, com
apenas 4 posies possveis de parada do rotor. Para converter esse movimento circular em
linear, o eixo gira sobre uma rosca sem fim, cujo comprimento associado ao dimetro do eixo
determina o nmero mximo de passos e o curso total do motor. Se denominarmos os
terminais de uma bobina de 1 e 3 e os da outra bobina de 2 e 4, teremos um diagrama de
sinais similar ao mostrado na Figura 49 para um motor de passo em movimento.
Se considerarmos ainda que o estado lgico do sinal de cada terminal um digito
binrio, podemos estabelecer que s existem quatro combinaes possveis formando quatro
nmeros binrios que se alternam. Esses nmeros podem ser lidos na vertical na mesma
Figura 49. Inicialmente o sistema simulador estava utilizando quatro entradas lgicas para
avaliar continuamente o estado dos quatro terminais do motor de passo. medida que os
nmeros binrios adquiridos se sucediam, eles eram comparados com o diagrama de fases
para se determinar o sentido de rotao do motor. No entanto a aquisio desses nmeros
atravs de uma porta digital de 4 bits tinha que ser feita um a um, pois nossas placas DAQ
no ofereciam a possibilidade de se estabelecer um taxa de aquisio contnua para sinais
digitais. Os atrasos gerados com a configurao da porta a cada aquisio estavam
ocasionando a perda de passos e, portanto o sistema estava indicando erroneamente a
posio atual do motor de passo. Atualmente essa porta digital est sendo usada apenas
para detectar estados no vlidos que podem representar problemas de mal-contato ou
defeito neste dispositivo e a contagem dos passos teve que ser feita conforme a descrio que
se segue.
Terminal 1
1 0 1 0 1
Terminal 2 1 1 0 0 1
Terminal 3 0 1 0 1 0
Terminal 4 0 0 1 1 0
- 78 -
Como os sinais em 3 e 4 so sempre o inverso dos sinais 1 e 2 respectivamente,
pois representam o outro terminal da mesma bobina, podemos lidar apenas com os dois
ltimos. Esse par de sinais similar aos fornecidos por codificadores de quadratura
(quadrature encoders), portanto utilizaremos seus conceitos para aquisio das informaes
de deslocamento do motor de passo. Codificadores so dispositivos que convertem
deslocamentos lineares ou circulares em sinais ou pulsos digitais. Nosso interesse recai
sobre os codificadores incrementais, que geram um pulso para cada passo incremental,
fornecendo maior resoluo a um menor custo. No caso de um movimento circular onde por
meio de uma trilha de cdigo gerado um pulso a cada volta de um eixo, por exemplo, a
freqncia do sinal gerado indica a velocidade de deslocamento, porm no suficiente para
determinar sua direo. Para tanto necessitamos de um codificador de dois canais ou de
quadratura, com duas trilhas de cdigo no eixo, usualmente defasadas em 90. Por
exemplo, se a borda de subida (ou de descida) do canal A preceder a equivalente do canal
B, pode-se determinar se o movimento no sentido horrio ou anti-horrio, de acordo com
a definio dos canais.
Os contadores/temporizadores disponveis nas placas DAQ tm uma srie de
facilidades, dentre as quais a habilidade de contar bordas no sinal conectado sua entrada
SOURCE, de forma incremental ou decremental de acordo com o estado lgico de um sinal
digital conectado sua entrada UP_DOWN. Observando novamente a na Figura 49, podemos
observar que no haveria nenhum problema aparente em se conectar diretamente os sinais
1 e 2 a essas entradas, pois as bordas de 1 sempre ocorrem num determinado estado de
2 quando em movimento num sentido e no estado inverso quando o movimento no sentido
oposto. No entanto, vibraes no eixo, rudo e/ou jitter no sinal poderiam gerar pulsos
esprios contados indevidamente. Para garantir a confiabilidade das nossas medies, ns
utilizamos o conversor de clock de quadratura (quadrature clock converter) LS7084, da LSI
Computer Systems Inc., que possui filtros passa-baixa para eliminar os efeitos de rudo e
jitter e executa a contagem das bordas num dos canais sempre verificando se tambm
houveram transiees no outro para evitar a contagem indevida. Esse CI fornece duas
sadas: um sinal que pulsa uma vez para cada contagem e um sinal com o sentido do
movimento; ambos podendo ser conectados diretamente s entradas SOURCE e UP_DOWN.
Como pudemos observar no diagrama de estados da Simulao mostrado na Figura
22, a monitorao do motor de passo feita por uma sub-mquina de estado independente,
que inicia suas atividades imediatamente aps o evento de key-on, pois nesse instante a
ECU comanda o motor de passo para retrair-se um nmero de passos superior ao nmero
mximo possvel. Isso faz com que ele gire vrias vezes em falso na rosca sem fim,
garantindo que o motor se encontra em sua posio inicial e fornecendo uma referncia de
posio confivel, uma vez que a partir daqui cada movimento anotado para que se
conhea a posio exata do motor a cada instante.
- 79 -
Leitura atravs de porta digital s usada para
detectar se o valor adquirido vlido.
Chegamos ento ao ltimo VI mencionado na Figura 43. Esse VI, mostrado na Figura
51 a seguir responsvel pela gerao dos sinais correspondentes aos:
Transdutores:
Ao contrrio dos sensores de freqncia, os transdutores representam o estado atual
de uma grandeza fsica atravs de um valor esttico de uma grandeza eltrica, claro que
este valor varia to rpido quanto varie a grandeza fsica correspondente no ambiente. O
nosso sistema se prope justamente a simular um ambiente, e no incio do trabalho essa
simulao era esttica tal qual os simuladores manuais atuais, ou seja, o simulador s
respondia atuao dos comandos do Tcnico no painel frontal. Como nenhuma pessoa
consegue modificar os controles que representam as grandezas fsicas do ambiente muito
rapidamente (comparando-se com a velocidade de processamento de um PC), a atualizao
dos valores dos transdutores est sendo feita somente quando necessrio.
No entanto, percebemos que esta condio no suficiente para atender fielmente as
simulaes dinmicas que nos propomos a realizar. Para a simulao de scripts essa
estratgia apresenta uma limitao na resoluo temporal disponvel h um tempo mnimo
permitido (que depende da velocidade de processamento do PC) entre a atualizao de dois
valores consecutivos. Quando da implementao futura de uma simulao realimentada
atravs de modelamentos de motores, essa limitao torna-se proibitiva, pois no podemos
dizer a um modelo que a presso do ar no coletor de admisso s pode ser alterada daqui a
1ms, por exemplo.
- 80 -
Esse problema s ser resolvido com a implementao de uma gerao de sinais
contnua a uma alta taxa de atualizao, e com a utilizao de um ou mais buffers de sada
para os valores dos transdutores a serem simulados.
Mesmo com essa limitao, foi implementado um comportamento especial para o
sinal da sonda lambda. A sonda lambda mede a quantidade de oxignio nos gases de escape
e serve como parmetro para que a ECU verifique se a titulao da mistura ar-combustvel
estava de acordo com o valor que ela esperava. Supondo que o Tcnico posicionasse o
controle da sonda para um valor que indique mistura pobre, a ECU passaria a atuar
fornecendo mais combustvel (aumentando o tempo de abertura dos bicos injetores, por
exemplo) e como no haveria uma resposta adequada da sonda, ela permaneceria injetando
combustvel em demasia at que o Tcnico modificasse esse valor! Apesar de no termos
conhecimento profundo quanto resposta de nenhum motor, razovel considerar que,
uma ECU que esteja funcionando corretamente pelo menos neste aspecto, ir aumentar a
quantidade de combustvel e essa atuao ser refletida na sonda lambda. Para tentar
atender a gregos e troianos, alm das simulaes normal do valor e de desconexo que
seguem os mesmo princpios dos outros transdutores, foi implementado uma simulao
chamada de pulsada, onde o valor simulado para a sonda lambda fica alternando entre o
valor indicado no controle do painel frontal e o valor correspondente a uma mistura na
relao estequiomtrica. O Tcnico seleciona o tipo de simulao desejada no painel frontal.
- 81 -
Finalmente chegamos ao painel frontal, j mencionado na Figura 41, sendo chamado
pelo Runtest.vi e na Figura 45, chamado pelo Interact.vi. No primeiro caso, o painel frontal
entra em modo de inicializao como pode ser visto abaixo.
- 82 -
Sinais das Entradas Digitais
e Atuadores de Potncia so
Indicadores para cannister
enviados para seus
e Motor de Passo recebem
respectivos indicadores.
ltimo valor adquirido.
- 83 -
As funcionalidades Hold Output e Run Script mencionadas no item 7.1 Executar
Teste (Simulao), so realizadas no trecho de cdigo mostrado na Figura 55 abaixo.
No modo Hold Output, ao invs de enviar o valor atual dos indicadores no painel,
deixamos a rea de Transferncia inalterada e a simulao continuar funcionando com o
ltimo status enviado.
No modo Run Script, o princpio o mesmo, mas enviamos valores oriundos de um
arquivo de script. Essa flexibilidade uma conseqncia direta da utilizao da rea de
Transferncia como interface entre os comandos executados no painel e o Bloco de Software
responsvel pela simulao.
- 84 -
Captulo 7 Realizao do Hardware
7.1 Mdulo de Condicionamento de Sinais
O mdulo de condicionamento de sinais o elemento de interface entre o produto sob
teste e as placas DAQ instaladas na plataforma utilizada, seja ela uma verso bancada ou
porttil. Este mdulo tem uma configurao mnima que deve ser respeitada a todo custo,
com poucos elementos que poderiam ser considerados opcionais. Portanto no existe a
possibilidade de se obterem vantagens significativas de tamanho ou peso que justificassem o
desenvolvimento de mltiplas configuraes desse mdulo, para um mesmo tipo de produto
a ser testado. O aproveitamento de um nico mdulo para diversos produtos uma
possibilidade ainda no descartada por completo, devido grande similaridade e
redundncia dos diversos sinais utilizados por produtos de eletrnica embarcada. Esse
aproveitamento poderia ser feito com o desenvolvimento de uma placa de circuito impresso
que proveja diversas funcionalidades, com somente algumas delas sendo utilizadas para
cada tipo de produto. Para minimizar o nmero de pinos nos conectores de entrada e sada
do mdulo, seriam utilizados jumpers para direcionar cada sinal a seu circuito de
tratamento correspondente. Esse mdulo deve possuir conectores padro para as placas e
um nico conector para a centralina sob teste, conforme discutido no Captulo 3.
Tendo em vista, mais uma vez, a aplicao de uma centralina como produto-piloto de
testes para efeito de validao do simulador, ser desenvolvido um mdulo de
condicionamento que atenda somente a seus requisitos. Utilizando a notao padronizada
no modelamento do simulador, podemos classificar os sinais da centralina em nove grupos
distintos, com diferentes requisitos: Transdutores, Sensores de Freqncia, Atuadores de
Potncia, Atuadores em Freqncia, Atuadores de Marcha Lenta, Entradas On-Off, Sadas
On-Off, Serial e Alimentao/Referncia. Vamos agora explorar as caractersticas de cada
grupo e agrupar caractersticas semelhantes para determinar os tipos de circuitos de
condicionamento adequados a cada um dos sinais.
Alimentao/Referncia:
Este ser o primeiro grupo a ser tratado por ser obviamente o mais fundamental para
o funcionamento da centralina e de toda a circuitaria presente no mdulo. Como veremos
mais adiante, estaro presentes no mdulo no somente circuitaria mas tambm vrias
cargas automotivas reais. E uma caracterstica da maioria dessas cargas que sua
alimentao realizada localmente. Assim o controle da centralina se resume em chavear a
carga para a massa, permitindo ou no a passagem de corrente e portanto sua atuao. Isso
implica na existncia de um barramento com a tenso da bateria capaz de aliment-las. Para
tanto iremos utilizar uma bateria automotiva com capacidade de 40Ah a uma tenso
nominal de 12V conectada ao mdulo, que poder ser substituda futuramente por uma
fonte de tenso DC varivel de 9-15V com capacidade de fornecimento de 10A. Por enquanto
assume-se que o uso do simulador seja restrito a locais aonde haja uma bateria disponvel.
- 85 -
Em um ambiente real, a alimentao desse barramento est condicionada ativao
do rel ''Pump" pela centralina, aps a ao de key-on ter sido executada pelo usurio. A
centralina tambm gerencia sua prpria alimentao atravs do rel "Power Latch". Para
verificar essa funcionalidade e garantir s centralinas um shut-down apropriado, essa
montagem ser implementada com dois rels e uma chave On-Off. Esses rels podero ser
isolados atravs de jumpers, caso em que a chave On-Off alimentar diretamente o
barramento e a centralina. Esta montagem pode ser observada na Figura 56. Nesta figura
podemos observar as conexes das bobina e chaves dos rels Power Latch e Pump e da
dupla chave On-Off, identificadas com os nmeros 1, 2 e 3, respectivamente.
PLATCH
1
VBATT
PUMP
2
GND
Figura 56: Conexo dos Rels Power Latch, Pump e Chave Key-On
- 86 -
Atuadores:
Os atuadores se dividem em trs grupos: de potncia, em freqncia e de marcha
lenta. Sua principal caracterstica em comum que, na maioria dos casos, o sistema requer
a existncia da carga real comandada pela centralina. As sadas On-Off tambm podem
opcionalmente estar conectadas a um rel automotivo ou a um resistor de pull-up.
Cargas Reais:
A presena fsica de algumas cargas reais torna-se imprescindvel quando suas
caractersticas, em geral indutivas e/ou variveis, tornam impossvel sua simulao ao nvel
de software. Testes da capacidade de fornecimento de corrente pelos drivers do produto,
curto-circuito massa e bateria, imunidade do sistema a spikes de tenso e outros, s
podem ser realizados em situaes pseudo-reais, utilizando as mesmas cargas que geram
no-linearidades em um ambiente automotivo.
A conexo dessas cargas com a eletrnica ser feita com os mesmos conectores
utilizados nos veculos em produo. Dessa forma, para cada modelo sob teste, somente as
cargas reais pertinentes a ele necessitam estar presentes. Estaro disponveis no mdulo de
condicionamento de sinais para uma centralina os conectores para as seguintes cargas reais:
Cada grupo de atuadores requer um tipo de circuitaria para condicionar seus sinais
de interesse: a corrente na carga, para os atuadores de potncia; o duty cycle, para os
atuadores em freqncia e a presena ou ausncia de tenso em cada fase do atuador de
marcha lenta.
Atuadores de Potncia:
Nossa sonda de corrente ser um resistor de valor conhecido conectado em srie com
a carga cuja corrente deve ser medida, sobre o qual medimos a tenso entre seus terminais.
O ampermetro ideal apresenta resistncia nula, caso limite onde sua presena no
influencia a corrente a ser medida; mas para fins prticos basta utilizarmos uma resistncia
muito menor do que a impedncia no resto da malha.
- 87 -
Os atuadores de potncia em questo so bicos injetores e bobinas de ignio. Estas
cargas possuem impedncias mnimas tpicas da ordem de 10 e 1, portanto iremos utilizar
sondas de 0.1 e 0.024 (3W-1% de preciso), cuja interferncia pode ser considerada
desprezvel. Apesar dessas correntes poderem chegar at 7.5A, elas s existem durante o
tempo de atuao de cada carga - tempo de injeo ou tempo de Dwell -, nunca superiores a
20 ms por ciclo motor; o que corresponde a uma dissipao mxima de potncia muito
pequena nos resistores (0.75W * 20ms = 15mJ), no representando perigo para o mesmo.
Cada sinal de tenso adquirido dever portanto ser inferior a 1V, porm muito
ruidoso. Esses sinais sero amplificados por amplificadores diferenciais de instrumentao
que tm como funes: melhorar a resoluo do sinal a ser adquirido pelas placas DAQ,
eliminar a tenso de modo comum e proteg-las contra possveis transientes de tenso. A
tenso mxima suportada por cada canal analgico nas placas DAQ, quando desligadas,
de 15V. Portanto para garantir a segurana das placas, a alimentao dos amplificadores
ser de 12V e o ganho dos amplificadores para cada tipo de carga deve permitir total
excurso do sinal na sada sem nunca chegar saturao, em condies normais de
operao.
Como exemplo, quando a centralina corta a atuao das cargas, a energia
armazenada nessas bobinas pode gerar picos de tenso reversa da ordem de at 300V com
durao de 100s. E por estarem todas alimentadas atravs do mesmo barramento, esse
rudo interfere em todas as cargas. Para evitar que esses transientes danifiquem os
amplificadores diferenciais, cada carga ter um par de diodos de free-wheeling conectados
em paralelo e conduzindo para o barramento de alimentao. O diodo 1N4148 tem uma
resposta rpida logo no incio do transiente, mas no suporta essa corrente por muito
tempo. Logo a seguir o 1N4007 entra em conduo e descarrega a maior parte da carga da
respectiva bobina. A Figura 57 mostra o esquemtico de um bloco de condicionamento
composto pela sonda de corrente, um amplificador diferencial de ganho 20 e os diodos de
proteo. O mdulo de condicionamento tem seis conjuntos como este disponveis.
- 88 -
O circuito conectado em paralelo com cada uma dessas cargas pode ser observado na
Figura 58, e o mdulo de condicionamento tem dez circuitos como este disponveis. O
mesmo circuito dever ser utilizado para adquirir os sinais TACHOM - uma repetio via
hardware do sinal de rotao fornecido pelo sistema simulador (quadro de sinais) e CONSUM
consumo de combustvel geralmente codificado em ciclo ativo, quando estes estiverem
presentes na centralina.
Figuras 58 e 59: Bloco Divisor de Tenso e Opo de rel para Sadas On-Off
- 89 -
Sadas On-Off:
As sadas On-Off em geral tambm funcionam com alimentao local, mas como as
cargas reais neste caso so os rels e no a carga realmente acionada, essa alimentao no
precisa ser necessariamente a tenso de bateria. Assim podemos alimentar os rels
diretamente com a nossa referncia de 5V, dispensando o condicionamento do sinal. Alm
disso, esses sinais no possuem funes de diagnstico pela centralina e sua caracterstica
indutiva indiferente, portanto podemos substituir os rels por resistores! Essa opo ser
feita atravs de jumpers, conforme a Figura 59. O mdulo de condicionamento tem cinco
circuitos como este disponveis.
Caso hajam sadas On-Off alimentadas pela centralina, devero ser utilizados
circuitos de condicionamento idnticos aos mostrados pela Figura 59.
Serial:
A comunicao serial com a centralina realizada atravs das linhas seriais K e L.
Dependendo da aplicao e com relao centralina, a linha K pode ser bidirecional ou de
sada e a linha L pode ser de entrada ou no estar em uso. O nico ponto em comum que,
como tudo no ambiente automotivo, o nvel lgico alto representado pela tenso de bateria
e o nvel lgico baixo pela massa. Por sua vez, a interface serial do computador opera em
padro RS-232.
Ao invs de projetar uma circuitaria que realizasse essa converso, separasse os
sinais de entrada e sada na linha K e provesse todas as protees para garantir a
integridade do computador, optamos por usar transceivers disponveis no mercado, fazendo
a converso em duas etapas. Primeiro utilizamos o CI patenteado Marelli TY93051 que
desloca os nveis das linhas K e L para nveis TTL. Em seguida utilizamos o chip MAX232
que converte nveis TTL para RS-232. A Figura 60 mostra o esquemtico do circuito j com
os conectores de ponte (JPR1 - JPR4) para fazer a opo de tipo de aplicao.
- 90 -
Entradas On-Off:
As entradas On-Off se classificam conforme o sinal interpretado quando ela no est
conectada (flutuante), ou seja, se possuem um resistor de Pull-Up ou um de Pull-Down. E
como tudo o mais, o nvel alto a tenso de bateria. A Figura 61 mostra circuitos
deslocadores de nvel para operar com uma entrada em Pull-up e com uma entrada em Pull-
Down, respectivamente. O mdulo de condicionamento tem cinco circuitos de cada tipo
disponveis.
Transdutores e Sensores:
Como a impedncia de entrada desses sinais na centralina muito alta, poderamos
conect-los diretamente das placas DAQ. No entanto, para facilitar a conexo, esses sinais
sero redirecionados dentro do mdulo de forma a termos somente um conector entre o
sistema e a centralina (os conectores entre o mdulo e o computador so considerados como
pertencentes ao sistema, pois independem do produto sob teste).
- 91 -
Para compreendermos melhor a realizao final do sistema na Figura 62 abaixo,
repetimos alguns elementos da Figura 10.
Signal Conditioning Module
Harness
- 92 -
As Figuras 63 e 64 a seguir, mostram mais alguns detalhes desse mdulo.
- 93 -
- 94 -
Captulo 8 Avaliao do Sistema
5
4,5
4
3,5
3
2,5
V
2
1,5
1
0,5
0
0 200 400 600 800 1000 1200 1400
P (m ba r)
5
4,5
4
3,5
3
2,5
V
2
1,5
1
0,5
0
-60 -40 -20 0 20 40 60 80 100 120 140
T (C)
- 95 -
Sensor de temperatura do lquido de arrefecimento modelo WTS05
- Funo de Transferncia (best fit): V=10.91*exp(10.91*T) (V, RPull-Up=2K)
Transducer / Temp W ater Sensor / W TS05
5
4,5
4
3,5
3
2,5
V
2
1,5
1
0,5
0
-60 -40 -20 0 20 40 60 80 100 120 140
T (C)
3
V
0
0 20 40 60 80 100 120 140
Ope ning Angle (de g)
1,2
0,8
0,6
V
0,4
0,2
0
0,88 0,9 0,92 0,94 0,96 0,98 1 1,02 1,04 1,06 1,08 1,1 1,12
La m bda
- 96 -
Sensor de detonao modelo KNE02
- Amplitude do sinal: V=16.917*R+319.832 (mV, 2-4<R<10 kHz)
120
100
80
Duty Cycle (% )
60
40
20
0
0 10 20 30 40 50 60 70 80
Throughput (%)
- 97 -
- 98 -
8.2 Resultados Obtidos
Devido ausncia de informaes detalhadas sobre os algoritmos internos de clculo
da centralina utilizada, no pudemos realizar uma verificao funcional do sistema de forma
quantitativa. Em uma verificao desse tipo, forneceramos um conjunto de valores dos
sensores para o qual conheceramos a resposta exata prevista da centralina e poderamos
comparar nossos valores adquiridos de tempo de injeo, p.e., com o valor esperado.
Uma grande parte da informao que tnhamos disponvel (alguns diagramas de bloco
com a estrutura bsica do Software e um programa de teste de fim de linha) tambm est
disponvel no CD que acompanha este trabalho. Como no conhecamos nenhuma resposta
exata prevista, tivemos que nos contentar com verificaes qualitativas. Enumeramos aqui
algumas delas:
1- Acionamento do rel de power latch (veja Figura 56: Conexo dos Rels Power Latch,
Pump e Chave Key-On)
AO: ao se acionar a chave de contato (em nosso caso a dupla chave On-Off), a centralina
recebe a tenso de bateria pelo pino PUMP e desperta.
REAO: Sua primeira ao acionar o rel de power latch para garantir sua alimentao
da tenso de bateria. Em seguida ela puxa o sinal do pino PUMP para massa o que
aciona o rel de pr-pressurizao da linha de combustvel. Logo em seguida ela deveria
comandar o motor de passo por alguns segundos para garantir que ele se encontra em fim
de curso e calibrar sua posio inicial.
- 99 -
7- Entrada em modo de Cut-Off
AO: borboleta em mnimo por mais de m PMS (v. calib.) E TH2O superior a um limite de
calibrao E rotao superior a um limite de calibrao E rotao retornou maior que limite
de calibrao aps o ltimo Cut-Off
REAO: tempo de injeo reduzido a zero (freio motor)
- 100 -
Captulo 9 Concluses
com muito prazer que temos hoje a confirmao das principais decises de projeto
tomadas, pois nesse meio-tempo a linguagem UML e a utilizao de placas DAQ se
estabeleceram definitivamente em todos os sistemas de teste utilizados pela indstria
automotiva mundial.
Outras decises confirmadas foram algumas das nossas tcnicas de programao
desenvolvidas para LabVIEW 4.1, como por exemplo:
a metodologia usada na traduo de diagramas de classe em cdigo
LabVIEW hoje o fabricante do mesmo j disponibiliza um pacote de
ferramentas (State Diagram Toolkit, disponvel apenas a partir do LabVIEW
7.0) para gerao automtica de cdigo a partir de um diagrama de estados. O
cdigo gerado apresenta a mesma estrutura que descrevemos no Item 5.4.
novas funes com conceitos de orientao a objeto a partir do LabVIEW6i
foram disponiblizados os chamados control references e property nodes
aumentando as possibilidades de encapsulamento de cdigo e poliformismo.
a adaptao do LabVIEW para programao orientada a objeto uma empresa
sueca desenvolveu um pacote de ferramentas (GOOP Inheritance Toolkit) que
prov suporte para todas as caractersticas de programao orientada a
objeto; declaraes formais de classe, criao e destruio de objetos, relaes
de herana, etc. Um tutorial e material informativo esto disponveis no CD
que acompanha essa dissertao.
a adaptao do LabVIEW para programao orientada a objeto outra
empresa alem desenvolveu outro pacote de ferramentas (ObjectVIEW) que
poderia ser considerado algo como um G++ (G, para linguagem grfica). No
momento ele s est disponvel em alemo, mesmo assim inclumos material
informativo no CD que acompanha essa dissertao.
- 101 -
- 102 -
9.1 Orientao para Futuras Expanses do Projeto
Nossa idia inicial era expandir o sistema para possibilitar tambm testes de outros
componentes, em especial chegamos a preparar prottipos para instrumentos combinados e
sistemas de alarme por ultra-som. Mas o que em muitos momentos foi um inconveniente
agora passa a ser uma grande vantagem. O grande lapso de tempo entre a execuo prtica
desse projeto em 97 98 e a defesa desta tese em 2004 por motivos profissionais, nos
proporciona uma perspectiva histrica que facilita em muito a anlise que se segue.
Falando um pouco do presente, a Figura 71 abaixo mostra o crescimento do nmero
de unidades eletrnicas conectadas em rede atravs de diversos barramentos (CAN em 100 e
500kbits/s, LIN, etc.) em veculos Volkswagen. O aumento da complexidade desses sistemas
eletrnicos automotivos resultou em uma nova definio das competncias essenciais para
as montadoras e os fornecedores de componentes eletrnicos.
- 103 -
O processo de desenvolvimento utilizado hoje em dia pela Volkswagen se baseia no
chamado Modelo V que pode ser visto na Figura 72 abaixo.
Esse modelo descreve os passos incrementais que devem ser tomados na definio de
sistemas eletrnicos complexos e a dualidade que existe entre especificao e
correspondente verificao, em diferentes nveis de abstrao. Na prtica, ele representa a
diviso de responsabilidades e tarefas entre os departamentos de engenharia da montadora e
os fornecedores. Vale tambm ressaltar a similaridade entre esse modelo e o escalonamento
de nveis de testes mencionado no Item 1.2.
Funcionalidade Rodagem de
Marketing, Diretoria Aprovao do Veculo
Diretoria
Especificaes de
Sistema Durabilidade,
Teste Intensivo em
Engenharia: Particionamento e Veculo (FIT) Engenharia
Teste em Veculo de
Sistemas Eletrnicos Definio de redes e
Referncia
plataformas HW&SW
Teste em Breadboard
Desenvolvimento
Engenharia: das Funes Testes em Bancada
dos Componentes Engenharia /
Componentes Eletrnicos Desenvolvimento com Simuladores Fornecedores
dos Componentes estticos e dinmicos
- 104 -
Figuras 73 e 74: Bancada de testes para componentes e Breadboard para sistemas de conforto[21]
O objetivo dessa discusso foi ressaltar melhor o papel que nosso sistema simulador
desempenha no ambiente automotivo atual. Para poder desempenhar sua funo de garantir
que cada componente individualmente est livre de falhas, temos dois tipos de necesidades
em aberto: mais recursos para simular os distintos ambientes aonde esse componente ser
montado; mais recursos para simular novos sensores/atuadores.
- 105 -
Com referncia ao primeiro tipo de necessidade, identificamos como recurso
absolutamente necessrio incorporao de interfaces para diversos tipos de barramentos
automotivos: CAN (alta e baixa velocidade) indispensvel; LIN altamente desejvel; Flex
Ray e TTP so recomendveis para garantir a utilizao do sistema a mdio-prazo; MOST e
Fire Wire se tornam interessantes caso haja interesse em expandir o sistema para teste de
sistemas de Infotainment.
Para simular distintos ambientes e situaes, temos necessidade de expandir o
mdulo de gerao de scripts e percursos para atender a distintos tipos de testes.
Especificamos aqui os tipos de teste desejados e suas respectivas funcionalidades:
Automtico
Dado um set de dados adquiridos em campo, o usurio seleciona um trecho do
percurso descrito e inicia o teste. O sistema simular o comportamento do veculo
para o dispositivo que est sendo testado, fornecendo-lhe os sinais correspondentes
em todos os pinos que requisitam entrada de dados. Simultaneamente, ele ir
tambm adquirir os sinais fornecidos pelo dispositivo e armazen-los em arquivo.
Paralelamente a essa transferncia de dados atravs da pinagem do dispositivo via
sinais eltricos no tratados, alguns dispositivos provm a possibilidade de se obter
os valores realmente compreendidos e/ou pretendidos pelo dispositivo via serial. Isto
, o sistema far a monitorao dos dados enviados e verificao da validade dos
dados recebidos consultando diretamente os registradores internos do dispositivo
periodicamente. O usurio escolhe quais sinais e como quer visualis-los: p.e. duty
cycle; grfico real time com os sinais esperado, adquirido e/ou pretendido; etc. Aps o
trmino do teste, o sistema avalia a discrepncia da resposta de cada sinal e reporta
ao usurio os sinais que violaram uma determinada tolerncia predefinida. Usurios
das reas de Qualidade e Assistncia Tcnica podem personalizar seus report files a
fim de evidenciar algum comportamento repetitivo e anmalo de algum(ns) sinal(is).
Dependendo da discrepncia de cada sinal o sistema tambm prover um diagnstico
simplificado e sugestes de solues bsicas para problemas simples.
Semi-Automtico
O usurio dever definir um estado inicial manualmente ou escolhido de um set de
dados. O sistema prover uma interface com visualizao de todos os parmetros
modificveis, que estaro sendo enviados continuamente ao dispositivo em teste. O
sistema proceder atualizao dos dados em dois possveis modos: com ou sem
realimentao. O primeiro efetuar clculos de correlao entre variaes nos
diferentes parmetros de entrada, a fim de determinar o prximo estado vlido para o
motor associado ao dispositivo. A determinao destas funes de correlao
configurvel pelo usurio para permitir sua adaptao a vrios motores e atualizao
medida que modelamentos mais precisos forem sendo desenvolvidos. O segundo
apenas uma implementao dos testes paramtricos realizados atualmente. O
sistema reportar apenas a comparao entre os sinais enviado e compreendido, visto
que o usurio varia os parmetros buscando algum comportamento particular do
dispositivo e no existe uma resposta padro esperada.
- 106 -
End-Of-Line (EOL)
O usurio pode cadastrar uma seqncia de testes EOL e associ-los a cada
dispositivo. Para isso necessrio especificar a string de ativao do modo EOL do
dispositivo (se existir). No entanto, devido a limitaes de hardware, sempre havero
alguns testes executados na linha de montagem que no podero ser realizados
(sobretenso, etc.). Isso no considerado um problema, visto que o teste EOL
apenas mais uma ferramenta que se aproveita dos recursos do sistema e no sua
finalidade principal.
Figura 77: Nveis de emisso nos EUA/Europa e tecnologias para esse fim[22]
- 107 -
Para sermos mais precisos, a Figura 78 abaixo mostra componentes necessrios para
atingir nveis PZEV (partial zero-emission vehicle) e SULEV (super-ultra-low-emission
vehicle). Nossa concluso ao observar esse sistema que se torna necessrio concentrar
futuros desenvolvimentos de nosso simulador em uma nica direo. A incrvel variedade de
tipos de sensores e atuadores torna virtualmente impossvel conceber algo que seja
adaptvel a qualquer tipo de sistema automotivo.
- 108 -
A nica soluo possvel para atender a esses objetivos aparentemente divergentes,
tendo em vista ainda o aumento da complexidade j mencionado, uma maior padronizao
dos sistemas utilizados.
Essa soluo j est em andamento e se chama AutOSAr (Automotive Open System
Architecture). No iremos entrar em mais detalhes alm do que se pode ver na Figura 79
abaixo, mas a mensagem que no devemos nos concentrar no teste de subcomponentes de
hardware e software porque no futuro os fornecedores de componentes automotivos j os
recebero pr-especificados e validados.
- 109 -
Acrescentando alguns pontos j mencionados no decorrer deste trabalho, resumimos
por fim nossa recomendao para as futuras expanses do sistema nos seguintes pontos:
Prover interfaces para redes automotivas CAN. LIN, etc.
Expandir e melhorar o mdulo de scripts para permitir diferentes tipos de testes
automatizados
Expandir e padronizar as formas de documentao dos resultados dos testes
Priorizar oficialmente as centralinas como foco de futuros desenvolvimentos e
adquirir recursos de hardware para simular os sinais necessrios para os futuros
motores em questo
Facilitar e automatizar a instalao do sistema
Importar o cdigo para a ltima verso do LabVIEW disponvel o sistema foi criado
na verso 4.1 e hoje j est disponvel a verso 7.0
- 110 -
9.2 Trabalhos Acadmicos
Como resultado deste trabalho foram apresentados os seguintes papers em eventos
internacionais:
Automotive Simulator for Electronic Fuel Injections SAEBrasil99 / So Paulo
Low-Cost Virtual-Instrumentation-Based Simulator for Electronic Fuel Injections
ISATA2000 / Dublin
- 111 -
- 112 -
Referncias Bibliogrficas
[1] Butler, K. R. and Wagner, J. R., A Strategy to Demonstrate the Compliance of Automotive
Controller Software to Systems Requirements Using Simulation Technology, SAE
Transactions Journal of Engines, Vol.103, Section 3, pp. 776-786
[2] S. Alles, C. Swick, M. Hoffman, S. Mahmud and F. Lin (1995) The Hardware Design of a
Real Time HITL for Traction Assist Simulation, IEEE Transactions on Vehicular
Technology, Vol. 44, N0. 3, pp. 668-682
[3] IEEE Standard Glossary of Software Engineering Terminology, ANSI/IEEE Standard
610.12, 1990
[4] ISO 11452-1...5, Prfverfahren fr Komponenten;
mais especialmente a emisso conjunta DIN ISO 11452-4 (Ausgabe: 2000-03)
e ainda ISO 7637-1, Methods of test
e DIN 40 839-3, Elektromagnetische Vertrglichkeit (EMV) in Straenfahrzeugen
[5] J. Wagner, R. Brunts, K. Kaster, D. Eagan and D. Anthony, (1999) A Vision for
Automotive Electronics Hardware-In-The-Loop Testing, International Journal of Vehicle
Design, Vol. 22, Nos. 1-2, pp. 14-28
[6] Luis Alejandro Corts y Antonio Garca, Proceso de Codiseo Hardware-Software, IV
Workshop Iberchip, Mar del Plata Argentina, Maro 1998
[7] Giovanni de Micheli, Computer-Aided Hardware-Software Codesign, IEEE Micro Vol.14
N 4, Agosto 1994
[8] A. Kalavade and E. A. Lee, A Hardware-Software Codesign Methodology for DSP
Applications, IEEE Design & Test, Vol. 10 N 3, pp. 16-28, September 1993
[9] J. K. Adams, D. E. Thomas, The Design of Mixed Hardware/Software Systems, 33rd
Design Automation Conference, 1996
[10] K. Newton, W. Steeds and T. K. Garret, The Motor Vehicle, Butterworths, 11th ed. 1989
[11] F. F. Schmidt, translated by R. W. Stuart Mitchell and J. Horne, The Internal
Combustion Engine, Chapman and Hall, 1965
[12] Automotive Engineering, Vol.9 N 5, Outubro 1984
[13] Automotive Handbook, Robert Bosch GmbH, 4th ed. October 1996
[14] Sistemas de Injeo e Ignio Eletrnicas, ISVOR-FIAT, Agosto 1991
[15] Wagner, J.R. and Furry, J. S. (1992), A Real Time Simulation Environment for the
Verification of Automotive Electronic Controller Software, International Journal of Vehicle
Design, Vol. 13, No. 4, pp. 365-377
- 113 -
[16] Data acquisition Fundamentals, Signal Conditioning Fundamentals for PC-Based Data
acquisition systems & Field Wiring and Noise Considerations for Analog Signals, AN 007,
025 & 048, available at http://www.natinst.com/appnotes.nsf, National Instruments, 1998
[17] James Rumbaugh et al, Object-Oriented Modeling and Design, Prentice Hall, 1990
[18] Derek Coleman et al, Object-Oriented Development: The Fusion Method, Prentice Hall, 1994
- 114 -
Apndice A Alguns Use Cases
- 115 -
RELATED 1. Modificar_Produto
INFORMATION
Priority: low
Performance 10 min
Frequency 1/ms
Channels to interativo
actors
OPEN ISSUES Definir atributos do produto
Conferir recursos do AutoSEFI
Due Date 13/01/1999
...any other
management
information...
Superordinates Configurar_Produtos (#4), Adicionar_Produto (#2)
Subordinates Selecionar_Parte (#3),
- 116 -
USE CASE 2 Adicionar_Produto
Goal in Configurador deseja acrescentar um novo produto Base
Context de Dados
Scope & Level Configurao de Produto, Subfuno
Preconditions
Success End Novo Produto acrescentado Base de Dados, conforme
Condition informaes fornecidas pelo Configurador
Failed End Base de Dados permanece inalterada
Condition
Primary, Configurador
Secondary
Actors
Trigger Requisio de criao de novo produto
DESCRIPTION Step Action
1 O Configurador requisita criao de novo produto
2 O Configurador fornece nome e pinagem do novo
produto
3 O sistema cria um novo produto, sem nenhum
componente nem interface de testes associados
4 O Configurador modifica esse novo produto
EXTENSIONS Step Branching Action
4a O Configurador no modificou o novo produto:
4a1. O sistema remove o novo produto da Base
de Dados.
RELATED 2. Adicionar_Produto
INFORMATION
Priority: Low
Performance 10 min
Frequency 1/ms
Channels to Interativo
actors
OPEN ISSUES Apresentao da Pinagem
Due Date 05/03/1999
...any other
management
information...
Superordinates Configurar_Produtos (#4)
Subordinates Selecionar_Parte (#3)
- 117 -
USE CASE 11 Executar Simulao em Produto
Goal in Tcnico deseja simular um ambiente automotivo para um
Context produto da Base de Dados
Scope & Level Resumo
Preconditions Produto existe na Base de Dados
Success End A simulao foi executada e os resultados foram
Condition apresentados em forma visual ou impressa.
Failed End Nao ocorreu simulao ou os resutados no foram
Condition apresentados ao Tcnico
Primary, Tcnico
Secondary
Actors
Trigger Requisio de Execuo de Simulao
DESCRIPTION Step Action
Inicializao 1 O Tcnico se identifica para o sistema
2 O Tcnico seleciona um produto e especifica um tipo
de simulao.
Configurao 3 O sistema adquire as informaes sobre o produto
da base de dados.
4 O sistema configura as placas DAQ e inicializa a
interface visual para o modo Simulao.
Simulao 5 O sistema apresenta o Painel Frontal para o Tcnico.
Simulao 6 O sistema simula um ambiente correspondente aos
(cont.) instantes que se seguem partida de um veculo,
fazendo com que o produto atue como se estivesse
em condies normais de operao.
7 O sistema executa concorrentemente os seguintes
processos:
7.1 O sistema atualiza as informaes relativas ao
estado atual das cargas controladas pelo produto e
as disponibiliza na rea de Transferncia.
7.2 O Painel Frontal apresenta as informaes presentes
na rea de Transferncia nos mostradores e grficos
e disponibiliza o estado atual dos controles e
interruptores na rea de Transferncia.
7.3 O sistema checa o estado dos controles e
interruptores presente na rea de Transferncia e
simula esse ambiente para o produto.
7.4 O Tcnico pode, a qualquer momento, requisitar ao
sistema a mudana para os modos Hold Outputs e
Run Script.
- 118 -
7.5 O Tcnico pode, a qualquer momento, interromper a
simulao atravs de interruptores representando os
eventos de parada do motor e Key-off.
Histrico 8 O Tcnico requisita ao sistema informaes sobre a
simulao.
9 O Tcnico termina a execuo do sistema.
EXTENSIONS Step Branching Action
Hold Outputs 7a O sistema armazena o estado atual dos controles e
interruptores e simula continuamente esse ambiente
para o produto.
O Tcnico pode alterar os valores de todos os
controles, respeitando seus limites de variao
instantnea, sem influir no ambiente que est sendo
simulado para o produto.
Aps executar as modificaes desejadas
repesentando o novo ambiente para o produto, o
Tcnico solicita ao sistema o retorno para o modo
Simulao.
Run Script 7b O sistema armazena o estado atual dos controles e
interruptores e simula continuamente esse ambiente
para o produto.
O sistema desabilita o Painel Frontal e apresenta a
interface de seleo de scripts para o Tcnico.
O Tcnico seleciona o script a ser simulado dentre
os disponveis na base de dados, ou edita um novo
script, podendo armazen-lo na base de dados.
O sistema apresenta o Painel Frontal, com os
controles e interruptores desabilitados.
O sistema executa o script, simulando o percurso
(ambiente variante no tempo) representado no
mesmo.
O Tcnico pode selecionar um novo script, retornar
ao modo Simulao ou interromper a simulao e
mudar para o modo Histrico.
VARIATIONS Branching Action
8 O Tcnico decide se esses resultados devem ser
armazenados na base de dados e/ou apresentados
em forma visual ou impressa.
9 O Tcnico pode executar uma nova simulao.
- 119 -
RELATED 11. Executar Simulao em Produto
INFORMATION
Priority: high
Performance muitas horas
Frequency vrias vezes por dia
Channels to Interativo
actors
OPEN ISSUES Definir formato de script
Due Date 13/01/1999
...any other
management
information...
Superordinates
Subordinates Checar Controles e Interruptores (#12)
- 120 -
USE CASE 12 Checar Controles e Interruptores
Goal in O sistema executa as aes tomadas pelo Tcnico durante
Context uma simulao
Scope & Level Simulao de Produto, Subfuno
Preconditions Uma simulao est em andamento
Success End O sistema compreendeu as aes tomadas pelo Tcnico e
Condition reagiu de acordo.
Failed End As aes tomadas pelo Tcnico foram ignoradas pelo
Condition sistema.
Primary, Tcnico
Secondary
Actors
Trigger Simulao foi iniciada
DESCRIPTION Step Action
1 O sistema executa concorrentemente os processos
de 2 a 4:
Sensores de 2.1 O Gerador de Sinais Frequenciais requisita para a
Frequncia rea de Transferncia um Container de Informaes
com o estado dos controles e interruptores
referentes aos Sensores de Frequncia.
2.2 O Gerador de Sinais Frequenciais cria as formas de
onda correspondentes s informaes recebidas.
2.3 O Gerador de Sinais Frequenciais as reproduz nos
canais de sada analgica apropriados.
Transdutores 3.1 O Gerador de Tenses requisita para a rea de
Transferncia um Container de Informaes com o
estado dos controles e interruptores referentes aos
Transdutores.
2.2 O Gerador de Tenses reproduz as informaes
recebidas nos canais de sada analgica
apropriados.
Sonda Lambda 3.1 O Gerador de Sonda Lambda requisita para a rea
de Transferncia um Container de Informaes com
o estado do controle referente ao valor da sonda.
3.2 O Gerador de Sonda Lambda calcula o duty cycle e a
frequncia do sinal de sonda lambda
correspondentes s informaes recebidas, para
simula uma variao realimentada entre o valor
recebido e lambda unitrio.
3.3 O Gerador de Sonda Lambda reproduz o sinal nos
canais de sada analgica apropriados.
- 121 -
Entradas On- 4.1 O Gerador de Sinais On-Off requisita para a rea de
Off Transferncia um Container de Informaes com o
estado dos controles referentes s Entradas On-Off e
aos interruptores referentes s cargas.
4.2 O Gerador de Sinais On-Off aciona as sadas digitais
correspondentes.
EXTENSIONS Step Branching Action
- 122 -
USE CASE 13 Atualizar Mostradores e Grficos
Goal in O sistema verifica as respostas do produto para o qual est
Context sendo executada uma simulao e as disponibiliza na rea
de Transferncia.
Scope & Level Simulao de Produto, Subfuno
Preconditions Uma simulao est em andamento
Success End O sistema compreendeu as respostas do produto e as
Condition disponibilizou na rea de Transferncia.
Failed End O estado dos mostradores e grficos na rea de
Condition Transferncia no corresponde ao estado atual do produto.
Primary, Tcnico
Secondary
Actors
Trigger Simulao foi iniciada
DESCRIPTION Step Action
1 O sistema executa concorrentemente os processos
de 2 a 4:
Atuadores de 2.1 O sistema adquire dos canais de entrada analgica
Potncia I apropriados a forma de onda da corrente no Atuador
(Injetores) de Potncia selecionado pelo Tcnico no Painel
Frontal.
2.2 O sistema disponibiliza os dados adquiridos na rea
de Transferncia.
Atuadores de 3.1 O sistema adquire dos canais de entrada analgica
Potncia II apropriados a forma de onda da corrente no Atuador
(Ignio) de Potncia e extrai as informaes sobre o Tempo
de Dwell e o ngulo de Avano da ignio.
3.2 O sistema disponibiliza os dados adquiridos na rea
de Transferncia.
Atuador de 4.1 O sistema adquire os sinais das fases e checa sua
Marcha Lenta polaridade.
4.2 O sistema acompanha duas fases do Atuador de
Marcha Lenta a fim de determinar sua posio exata
e a disponibiliza na rea de Transferncia.
Atuadores em 5.1 O sistema adquire a frequncia e o duty cycle dos
Frequncia sinais frequenciais provenientes dos Atuadores em
Frequncia.
5.2 O sistema disponibiliza essas informaes na rea
de Transferncia.
Sadas On-Off 6 O sistema adquire os estados das Sadas On-Off e os
disponibiliza na rea de Transferncia.
- 123 -
Sincronismo 7 O sistema utiliza o sinal correspondente ao "Quadro
Segnali" a fim de estabelecer uma referncia
temporal para a simulao.
EXTENSIONS Step Branching Action
- 124 -
USE CASE 14 Apresentar no Painel Frontal
Goal in O sistema verifica as aes tomadas pelo Tcnico durante
Context uma simulao e as disponibiliza na rea de Transferncia,
bem como verifica na na rea de Transferncia as respostas
do produto para o qual est sendo executada uma
simulao e as apresenta para o Tcnico
Scope & Level Simulao de Produto, Subfuno
Preconditions Uma simulao est em andamento
Success End O sistema apresentou o estado atual do produto para o
Condition Tcnico e ir reagir de acordo as aes tomadas pelo
Tcnico.
Failed End O estado dos mostradores e grficos no corresponde ao
Condition estado atual do produto e/ou as aes tomadas pelo
Tcnico sero ignoradas pelo sistema.
Primary, Tcnico
Secondary
Actors
Trigger Simulao foi iniciada
DESCRIPTION Step Action
1 O sistema fornece ao Painel Frontal as informaes
disponveis na rea de Transferncia.
2 O Painel Frontal atualiza as informaes nos
mostradores e grficos.
3 O Painel Frontal checa requisies de mudana do
modo de simulao e eventos de parada do motor e
Key-off e as processa.
4 O Painel Frontal checa a atuao do Tcnico em
todos os controles e interruptores e atualiza as
informaes da rea de Transferncia.
EXTENSIONS Step Branching Action
VARIATIONS Branching Action
- 125 -
USE CASE 15 Adquirir Informaes sobre Produto
Goal in Disponibilizar na rea de Transferncia as informaes
Context sobre o produto selecionado disponveis na Base de Dados.
Scope & Level Simulao de Produto, Subfuno
Preconditions O Tcnico selecionou um produto para uma simulao
Success End As informaes sobre o produto selecionado foram
Condition disponibilizadas na rea de Transferncia.
Failed End A rea de Transferncia no contm informaes sobre o
Condition produto selecionado.
Primary, Tcnico
Secondary
Actors
Trigger Produto foi selecionado
DESCRIPTION Step Action
1 O sistema adquire as informaes sobre o Produto
selecionado pelo Tcnico da base de dados.
2 O sistema disponibiliza essas informaes na rea
de Transferncia.
EXTENSIONS Step Branching Action
1a No h informao suficiente associada ao produto
para executar uma simulao:
1a1. O sistema solicita a seleo de um outro
produto e volta ao passo 1.
VARIATIONS Branching Action
- 126 -
USE CASE 16 Configurar as Placad DAQ
Goal in Preparar o sistema para uma simulao.
Context
Scope & Level Simulao de Produto, Subfuno
Preconditions As informaes sobre o produto selecionado esto
disponveis na rea de Transferncia.
Success End O sistema est preparado para incio imediato de uma
Condition simulao
Failed End O sistema no est preparado para incio imediato de uma
Condition simulao
Primary, Tcnico
Secondary
Actors
Trigger Produto foi selecionado
DESCRIPTION Step Action
1 O sistema configura canais de sada analgica de
acordo com as informaes sobre os Transdutores
(em especial a Sonda Lambda) associados ao
Produto presentes na rea de Transferncia.
2 O sistema configura canais de sada analgica de
acordo com as informaes sobre os Sensores de
Frequncia associados ao Produto presentes na rea
de Transferncia.
3 O sistema configura canais de sada digital de
acordo com as informaes sobre, as Entradas On-
Off e os interruptores referentes s cargas e aos
eventos de parada do motor e Key-off, associadas ao
Produto presentes na rea de Transferncia.
4 O sistema configura canais de entrada analgica de
acordo com as informaes sobre os Atuadores de
Potncia (em especial a Ignio) associados ao
Produto presentes na rea de Transferncia.
5 O sistema configura um canal de entrada analgica
de acordo com as informaes sobre o Quadro
Segnale associado ao Produto presentes na rea de
Transferncia.
6 O sistema configura canais de entrada frequencial
de acordo com as informaes sobre os Atuadores
em Frequncia associados ao Produto presentes na
rea de Transferncia.
7 O sistema configura um canal de entrada
- 127 -
frequencial e um canal de entrada digital de acordo
com as informaes sobre os Atuadores de Marcha
Lenta associados ao Produto presentes na rea de
Transferncia.
8 O sistema configura canais de entrada digital de
acordo com as informaes sobre as Sadas On-Off
associadas ao Produto presentes na rea de
Transferncia.
9 O sistema disponibiliza todas as informaes de
configurao na rea de Transferncia.
EXTENSIONS Step Branching Action
1a
VARIATIONS Branching Action
- 128 -
USE CASE 17 Inicializar a Interface Visual
Goal in Preparar o sistema para uma simulao.
Context
Scope & Level Simulao de Produto, Subfuno
Preconditions As informaes sobre a configurao do sistema para a
simulao a ser iniciada esto disponveis na rea de
Transferncia.
Success End O Tcnico pode comear a interagir com a interface visual
Condition de simulao que lhe foi apresentada.
Failed End No foi apresentada interface visual de simulao para o
Condition Tcnico.
Primary, Tcnico
Secondary
Actors
Trigger O sistema foi configurado para iniciar uma simulao
DESCRIPTION Step Action
1 O sistema requisita ao Painel Frontal a inicializao
da interface visual. Esta interface possui:
* controles correspondendo a todos os sinais
de entrada requeridos pelo produto;
* mostradores e grficos correspondendo s
informaes relevantes sobre a atuao do produto
sobre suas cargas;
* interruptores com a capacidade de simular
a desconexo de sensores e cargas.
2 O Painel Frontal inicializa todos os controles,
interruptores, mostradores e grficos conforme as
informaes sobre o Produto selecionado pelo
Tcnico presentes na rea de Transferncia.
EXTENSIONS Step Branching Action
1a
VARIATIONS Branching Action
- 129 -
USE CASE 18 Disponibilizar Informaes na rea de Transferncia
Goal in Propiciar um mecanismo de troca de informaes entre
Context mtodos concorrentes que compense a falta de sincronismo
inerente ao processo.
Scope & Level Simulao de Produto, Subfuno
Preconditions
Success End O Container de Informaes recebido est disponvel para
Condition consulta.
Failed End O Container de Informaes recebido no est disponvel
Condition para consulta.
Primary, Tcnico
Secondary
Actors
Trigger
DESCRIPTION Step Action
1 A rea de Transferncia recebe um Container de
Informaes.
2 A rea de Transferncia armazena o Container no
buffer correspondente ao tipo de informao
transportada.
3 A rea de Transferncia atualiza os registros sobre
o histrico da simulao e de escrita do buffer.
EXTENSIONS Step Branching Action
1a
VARIATIONS Branching Action
- 130 -
USE CASE 19 Checar Informaes na rea de Transferncia
Goal in Propiciar um mecanismo de troca de informaes entre
Context mtodos concorrentes que compense a falta de sincronismo
inerente ao processo.
Scope & Level Simulao de Produto, Subfuno
Preconditions
Success End O Container de Informaes solicitado foi entregue.
Condition
Failed End O Container de Informaes solicitado no pode ser
Condition entregue.
Primary, Tcnico
Secondary
Actors
Trigger
DESCRIPTION Step Action
1 A rea de Transferncia recebe uma requisio de
informaes.
2 A rea de Transferncia fornece um Container de
Informaes com as informaes do tipo requisitado
que foram armazenadas no buffer correspondente
aps a ltima requisio.
3 A rea de Transferncia atualiza os registros sobre o
histrico de leitura do buffer.
EXTENSIONS Step Branching Action
1a
VARIATIONS Branching Action
- 131 -
- 132 -
Apndice B Lista de VIs
Na biblioteca Corefiles.llb
About.vi
VI para mostrar a mensagem de About do sistema simulador
Front Panel
Elements:
Control #1 (bool) Ok Close about screen
Control #2 (bool) About?(F) Selects between about or loading screens
Control #3 (string) Version Version number retrieved from the ini file
Control #4 (string) Date Version date retrieved from the ini file
Indicator (string) Version Info Information regarding this version number and date
#1
Indicator (string) Message Loading message
#2
AutoSEFI.vi
VI de inicializao, que l os parmetros do arquivo autosefi.ini,
verifica se h erros e inicializa o Engine.VI
Front Panel
Elements:
Engine.vi
VI que solicita a identificao do usurio e apresenta a tela
inicial do sistema simulador, de onde se acessam os diferentes
recursos de cadastro, simulaco, etc.
Front Panel
Elements:
Control #1 (bool) products Edit the parts Database, modifying, adding or removing
products
Control #2 (bool) test Run a test in a product registered in the Database
Control #3 (bool) components Edit the parts Database, modifying, adding or removing
components
Control #4 (bool) exit Exit AutoSEFI
Control #5 (bool) reports Analyze reports retrieved from the test histories Database
Control #6 (path) Base Path Specifies the base path where AutoSEFI has been installed
Control #7 (bool) about About AutoSEFI
- 133 -
Inifiles.vi
VI desenvolvido por Eric R. Nelson, Ph.D, da empresa Valiant
Technology, para edio de arquivos .ini
Front Panel
Elements:
LogIn.vi
VI para verificao da identidade do usurio. Utiliza as
informaes cadastradas no arquivo encriptado Users.id
Front Panel
Elements:
Control #1 (string) Login The login provided by the user in this session
Control #2 (string) Password The password for the user in this session
Control #3 (cluster) User Model A cluster containing the register information model for an user.
It has the following fields:
Control #3.1 (string) Name Full name of the user
Control #3.2 (string) Login Nickname chosen by the user
Control #3.3 (string) Password Password associated with the login
Control #3.4 (array) Privileges An array of Actors representing wich packages may be
used by the user. In the current version, AutoSEFI takes
in count only the privileges of the first Actor in the array
Control (enum) Actor The possible roles the user can play with the system. A
#3.4.1 role is specified through the access permission to a
package of the system. Possible values for this version
are {Technician, Engineer, Manager}
Control #4 (bool) Ok Validates user identity
Control #5 (bool) Cancel Cancel idendity validation
Control #6 (path) Base Path Specifies the base path where AutoSEFI has been installed
Control #7 (bool) Administrator?(F) Is this an administrator login for security issues?
Indicator (array) Privileges An array of Actors representing wich packages may be used by
#1 the logged user. In the current version, AutoSEFI takes in count
only the privileges of the first Actor in the array. It will contain a
null elements array if the login is unsuccessful
Indicator (enum) Actor The possible roles the user can play with the system. A
#1.1 role is specified through the access permission to a
package of the system. Possible values for this version are
{Technician, Engineer, Manager}
Indicator (path) Database Base Specifies the base path where the Parts Database is stored
#2 Path
- 134 -
Na biblioteca DataBaseManagement.llb
CADASTRO.VI
This VI selects a component type, interactively showing all the
parameters associated with the type. Then it calls 'Compsel.VI'
and if it returns a non-empty path, lets the user edits the
component parameters and saves it
Front Panel Elements:
Control #1 (cluster) Sensor I A cluster containing the registration attributes of a Transducer
Control #1.1 (ring) Sensor Type Indicates the kind of transducer for this component. It is
used by the system to organize the Database
Control #1.2 (string) Model The name to serve as a reference for the component in the
Database
Control #1.3 (dbl) Maximum The maximum value (in Volts) this signal can assume
Value
Control #1.4 (string) Transfer The transfer function that fits better the points in the
Function Values Table.This information is not being used in the
current version
Control #1.5 (array) Values Table A look-up table with the conversion of physical to voltage
unities for this component
Control #2 (bool) Ok
Control #3 (cluster) Sensor II A cluster containing the registration attributes of a Frequency
Sensor
Control #3.1 (ring) Sensor Type Indicates the kind of frequency sensor for this component.
It is used by the system to organize the Database
Control #3.2 (string) Model The name to serve as a reference for the component in the
Database
Control #3.3 (dbl) Maximum The maximum value (in Volts) this signal can assume
Value
Control #3.4 (string) Amplitude The transfer function relating the amplitude with the
Function frequency of the signal.This information is not being used
in the current version
Control #4 (cluster) Actuator II A cluster containing the registration attributes of a Frequency
Actuator
Control #4.1 (ring) Actuator Type Indicates the kind of frequency actuator for this
component. It is used by the system to organize the
Database
Control #4.2 (string) Model The name to serve as a reference for the component in the
Database
Control #4.3 (dbl) Operating The operating frequency for the duty cycle of the
Frequency component
Control #4.4 (array) Values Table A look-up table with the conversion of physical to duty
cycle unities for this component
Control #5 (cluster) Actuator I A cluster containing the registration attributes of a Power
Actuator
Control #5.1 (ring) Actuator Type Indicates the kind of power actuator for this component. It
is used by the system to organize the Database
Control #5.2 (string) Model The name to serve as a reference for the component in the
Database
Control #5.3 (dbl) Opening/Rise Time spent to open the injector or time to charge the
- 135 -
Time (usec) ignition coil
Control #5.4 (dbl) Closing/Spark Time spent to close the injector or duration time of the
Time (usec) spark produced by the ignition coil
Control #6 (cluster) Idle Speed A cluster containing the registration attributes of a Idle Speed
Control #6.1 (ring) Control Type Indicates the kind of idle speed control for this
component. It is used by the system to organize the
Database
Control #6.2 (string) Model The name to serve as a reference for the component in the
Database
Control #6.3 (dbl) Number of The maximum number of steps for Stepper Motors or the
Steps/Operatin operating frequency of the duty cycle for DC Motors
g Frequency
Control #6.4 (array) Forward Step A table containing the valid ordered binary numbers
Phase Sequence representing the phase signals of a stepper motor
Control #7 (bool) cancel
Control #8 (bool) Extend
Control #9 (ring) Type The type of component according to the subdivision in 9 signal
groups: Transducers, Frequency Sensors, Power Actuators,
Frequency Actuators, Idle Speed Actuators, On/Off Inputs,
On/Off Outputs, Serial and Power Supply/Reference
Control #10 (path) Database Base Path Specifies the base path where the Parts Database is stored
CADPROD.VI
- 136 -
ConfigProd.VI
Front Panel
Elements:
Control #1 (ring) Product The type of product among the three supported by AutoSEFI:
Electronic Control Units for Fuel Injection Systems (E.C.U.s),
Dashboards and Alarm Devices
Control #2 (bool) Ok
Control #3 (cluster) Panel
Control #3.1 (string) Model
Control #4 (cluster) Alarm
Control #4.1 (string) Model
Control #5 (bool) cancel
Control #6 (cluster) ECU A cluster containing the registration attributes of an ECU
Control #6.1 (string) Model The name to serve as a reference for the component in the
Database
Control #6.2 (array) Pin-Out An array of Pins (clusters containing the attributes of a
pin)
Control (ring) Type The type of signal connected in the pin among the
#6.2.1 groups: Transducers, Frequency Sensors, Power
Actuators, Frequency Actuators, Idle Speed Actuators,
On-Off Inputs, On-Off Outputs, Serial and Power &
Reference
Control (string) Name The name or relative path of the component associated
#6.2.2 with the pin
Control (u8) System Pin Number of the correspondent pin in the system
#6.2.3 connector
Control #6.3 (u8) Max Pins Number of pins at the ECU connector
Control #6.4 (string) Associated Contains the relative path of the user interface panel
Panel associated with this product
Control #7 (path) Database Base Specifies the base path where the Parts Database is stored
Path
EditProd.vi
Front Panel
Elements:
Control #1 (array) ECU Pin-Out An array of Pins (clusters containing the attributes of a pin)
Control #1.1 (string) Name The name or relative path of the component associated
with the pin
Control #1.2 (u16) Type The type of signal connected in the pin
Control #1.3 (bool) Apertou
Control #2 (cluster) Pin Cluster containing the attributes of a pin
Control #2.1 (string) Name The name or relative path of the component associated
with the pin
Control #2.2 (u16) Type The type of signal connected in the pin
Control #2.3 (bool) Apertou
Control #3 (path) Database Base Specifies the base path where the Parts Database is stored
- 137 -
Path
Control #4 (bool) change? Choose a new user interface panel
Control #5 (bool) Ok
Control #6 (bool) cancel
Control #7 (bool) Up
Control #8 (bool) Down
Control #9 (cluster) ECU In A cluster containing the registration attributes of an ECU
Control #9.1 (string) Model The name to serve as a reference for the component in the
Database
Control #9.2 (array) Pin-Out An array of Pins (clusters containing the attributes of a
pin)
Control (ring) Type The type of signal connected in the pin among the
#9.2.1 groups: Transducers, Frequency Sensors, Power
Actuators, Frequency Actuators, Idle Speed Actuators,
On-Off Inputs, On-Off Outputs, Serial and Power &
Reference
Control (string) Name The name or relative path of the component associated
#9.2.2 with the pin
Control (u8) System Pin Number of the correspondent pin in the system
#9.2.3 connector
Control #9.3 (u8) Max Pins Number of pins at the ECU connector
Control #9.4 (string) Associated Contains the relative path of the user interface panel
Panel associated with this product
Indicator (cluster) ECU Out A cluster containing the registration attributes of an ECU
#1
Indicator (string) Model The name to serve as a reference for the component in the
#1.1 Database
Indicator (array) Pin-Out An array of Pins (clusters containing the attributes of a
#1.2 pin)
Indicator (ring) Type The type of signal connected in the pin among the
#1.2.1 groups: Transducers, Frequency Sensors, Power
Actuators, Frequency Actuators, Idle Speed Actuators,
On-Off Inputs, On-Off Outputs, Serial and Power &
Reference
Indicator (string) Name The name or relative path of the component associated
#1.2.2 with the pin
Indicator (u8) System Pin Number of the correspondent pin in the system
#1.2.3 connector
Indicator (u8) Max Pins Number of pins at the ECU connector
#1.3
Indicator (string) Associated Contains the relative path of the user interface panel
#1.4 Panel associated with this product
Indicator (string) Model The name to serve as a reference for the component in the
#2 Database
Indicator (string) Associated Panel Contains the relative path of the user interface panel associated
#3 with this product
Indicator (array) Pin No.
#4
Indicator (bool) Remove Product?
#5 (F)
- 138 -
EditProd1.vi
Front Panel
Elements:
Control #1 (array) ECU Pin-Out An array of Pins (clusters containing the attributes of a pin)
Control #1.1 (string) Name The name or relative path of the component associated
with the pin
Control #1.2 (u16) Type The type of signal connected in the pin
Control #1.3 (bool) Apertou
Control #2 (cluster) Pin Cluster containing the attributes of a pin
Control #2.1 (string) Name The name or relative path of the component associated
with the pin
Control #2.2 (u16) Type The type of signal connected in the pin
Control #2.3 (bool) Apertou
Control #3 (path) Database Base Specifies the base path where the Parts Database is stored
Path
Control #4 (bool) change? Choose a new user interface panel
Control #5 (bool) Ok
Control #6 (bool) cancel
Control #7 (bool) Up
Control #8 (bool) Down
Control #9 (cluster) ECU In A cluster containing the registration attributes of an ECU
Control #9.1 (string) Model The name to serve as a reference for the component in the
Database
Control #9.2 (array) Pin-Out An array of Pins (clusters containing the attributes of a
pin)
Control (ring) Type The type of signal connected in the pin among the
#9.2.1 groups: Transducers, Frequency Sensors, Power
Actuators, Frequency Actuators, Idle Speed Actuators,
On-Off Inputs, On-Off Outputs, Serial and Power &
Reference
Control (string) Name The name or relative path of the component associated
#9.2.2 with the pin
Control (u8) System Pin Number of the correspondent pin in the system
#9.2.3 connector
Control #9.3 (u8) Max Pins Number of pins at the ECU connector
Control #9.4 (string) Associated Contains the relative path of the user interface panel
Panel associated with this product
Indicator (cluster) ECU Out A cluster containing the registration attributes of an ECU
#1
Indicator (string) Model The name to serve as a reference for the component in the
#1.1 Database
Indicator (array) Pin-Out An array of Pins (clusters containing the attributes of a
#1.2 pin)
Indicator (ring) Type The type of signal connected in the pin among the
#1.2.1 groups: Transducers, Frequency Sensors, Power
Actuators, Frequency Actuators, Idle Speed Actuators,
On-Off Inputs, On-Off Outputs, Serial and Power &
Reference
Indicator (string) Name The name or relative path of the component associated
#1.2.2 with the pin
- 139 -
Indicator (u8) System Pin Number of the correspondent pin in the system
#1.2.3 connector
Indicator (u8) Max Pins Number of pins at the ECU connector
#1.3
Indicator (string) Associated Contains the relative path of the user interface panel
#1.4 Panel associated with this product
Indicator (string) Model The name to serve as a reference for the component in the
#2 Database
Indicator (string) Associated Panel Contains the relative path of the user interface panel associated
#3 with this product
Indicator (array) Pin No.
#4
Indicator (bool) Remove Product?
#5 (F)
Indicator (u32) Pressed Pin Product pin to be edited
#6
MESSAGES.VI
This Vi displays the simulator's error and warning messages in
a Dialog Box form
Front Panel
Elements:
Control #1 (i32) Message Number The number of the desired message
Control #2 (bool) With Cancel? Display or not the 'Cancel' button Default value is FALSE
Control #3 (string) ExtraInfo
Indicator (string) Message The displayed message according to Message Number
#1
Indicator (u32) Ok/Cancel Reflects the user's action. 0 means that OK was the button
#2 pressed
NAMESEL.VI
This VI selects a name to be a reference for a component or
group of components from Compsel.VI and checks its validity
Front Panel Elements:
Control #1 (string) Name
Control #2 (bool) Group Will the name to be chosen probably be a Group of
components?
Control #3 (bool) Ok
Control #4 (bool) Cancel
Control #5 (enum) Name Type The type of the name to be selected: Component, Product or a
General Use one
Indicator (string) Name Out Name chosen
#1
Indicator (bool) Group? Out Is the name chosed a Group of components?
#2
Indicator (string) group
#3
Indicator (string) comp
#4
- 140 -
PARTSEL.VI
This VI works with the Products & Components (Parts)
Database, through the following actions: creating empty parts of
the desired type, deleting and modifying them, grouping them
for easier manipulation or only selecting a part to get its path.
OBS: This VI was built with the intention of making every file
operations transparent in respect to the final user of the system.
In this way, all the information presented on the front panel
shows parts and groups of parts referencing files and directories
respectively
Front Panel
Elements:
Control #1 (u16) Component/Prod Selects the part subtype whithin the following possible options:
uct/Panel Type - Component
0- Transducer(SensorI)
1- Frequency Sensor(Sensor II)
2- Power Actuator(ActuatI)
3- Frequency Actuator(ActuatII)
4- Idle Speed Actuator(IdlSpeed)
- 141 -
PARTSEL1.VI
This VI works with the Products & Components (Parts)
Database, through the following actions: creating empty parts of
the desired type, deleting and modifying them, grouping them
for easier manipulation or only selecting a part to get its path.
OBS: This VI was built with the intention of making every file
operations transparent in respect to the final user of the system.
In this way, all the information presented on the front panel
shows parts and groups of parts referencing files and directories
respectively
Front Panel
Elements:
Control #1 (u16) Component/Prod Selects the part subtype whithin the following possible options:
uct/Panel Type - Component
0- Transducer(SensorI)
1- Frequency Sensor(Sensor II)
2- Power Actuator(ActuatI)
3- Frequency Actuator(ActuatII)
4- Idle Speed Actuator(IdlSpeed)
- 142 -
PRODEDIT.VI
Front Panel
Elements:
Control #1 (listbox) Component List List of the components, of the type selected in the ring beside,
that are currently associated with this product. Empty spaces
may appear between the names during a session with add and
change operations and should be disregarded
Control #2 (bool) add Adds a new component of the type selected in the ring beside
Control #3 (bool) mod
Control #4 (bool) del
Control #5 (bool) Ok
Control #6 (bool) cancel
Control #7 (bool) change Choose a new user interface panel
Control #8 (ring) Type The type of component according to the subdivision in 9 signal
groups: Transducers, Frequency Sensors, Power Actuators,
Frequency Actuators, Idle Speed Actuators, On/Off Inputs,
On/Off Outputs, Serial and Power Supply/Reference
Control #9 (cluster) ECU In
Control #9.1 (string) Model A string corresponding to the product's model name, and
therefore its reference name in the Database
Control #9.2 (array) Transducers Array of strings, each one containing the name of a
component and its type, in the format: "type/name.cmp"
Control #9.3 (array) Frequency Array of strings, each one containing the name of a
Sensors component and its type, in the format: "type/name.cmp"
Control #9.4 (array) Actuators Type Array of strings, each one containing the name of a
I component and its type, in the format: "type/name.cmp"
Control #9.5 (array) Actuators Type Array of strings, each one containing the name of a
II component and its type, in the format: "type/name.cmp"
Control #9.6 (string) Idle Speed A string containing the name of the component and its
Actuator type, in the format:
"type/name.cmp"
Control #9.7 (string) Associated A string containing the name of the associated panel:
Panel "name.vi"
Control (cluster) ECU Out Std
#10
Control (string) Model A string corresponding to the product's model name, and
#10.1 therefore its reference name in the Database
Control (array) Transducers Array of strings, each one containing the name of a
#10.2 component and its type, in the format: "type/name.cmp"
Control (array) Frequency Array of strings, each one containing the name of a
#10.3 Sensors component and its type, in the format: "type/name.cmp"
Control (array) Actuators Type Array of strings, each one containing the name of a
#10.4 I component and its type, in the format: "type/name.cmp"
Control (array) Actuators Type Array of strings, each one containing the name of a
#10.5 II component and its type, in the format: "type/name.cmp"
Control (string) Idle Speed A string containing the name of the component and its
#10.6 Actuator type, in the format:
"type/name.cmp"
Control (string) Associated A string containing the name of the associated panel:
#10.7 Panel "name.vi"
- 143 -
Control (path) Database Base
#11 Path
Indicator (string) Model The name to serve as a reference for the component in the
#1 Database
Indicator (string) Associated Panel Contains the relative path of the user interface panel associated
#2 with this product
Indicator (cluster) ECU Out
#3
Indicator (string) Model A string corresponding to the product's model name, and
#3.1 therefore its reference name in the Database
Indicator (array) Transducers Array of strings, each one containing the name of a
#3.2 component and its type, in the format: "type/name.cmp"
Indicator (array) Frequency Array of strings, each one containing the name of a
#3.3 Sensors component and its type, in the format: "type/name.cmp"
Indicator (array) Actuators Type Array of strings, each one containing the name of a
#3.4 I component and its type, in the format: "type/name.cmp"
Indicator (array) Actuators Type Array of strings, each one containing the name of a
#3.5 II component and its type, in the format: "type/name.cmp"
Indicator (string) Idle Speed A string containing the name of the component and its
#3.6 Actuator type, in the format:
"type/name.cmp"
Indicator (string) Associated A string containing the name of the associated panel:
#3.7 Panel "name.vi"
PRODEDIT1.VI
Front Panel
Elements:
Control #1 (listbox) Component List List of the components, of the type selected in the ring beside,
that are currently associated with this product. Empty spaces
may appear between the names during a session with add and
change operations and should be disregarded
Control #2 (bool) add Adds a new component of the type selected in the ring beside
Control #3 (bool) mod
Control #4 (bool) del
Control #5 (bool) Ok
Control #6 (bool) cancel
Control #7 (bool) change Choose a new user interface panel
Control #8 (ring) Type The type of component according to the subdivision in 9 signal
groups: Transducers, Frequency Sensors, Power Actuators,
Frequency Actuators, Idle Speed Actuators, On/Off Inputs,
On/Off Outputs, Serial and Power Supply/Reference
Control #9 (cluster) ECU In
Control #9.1 (string) Model The name to serve as a reference for the component in the
Database
Control #9.2 (array) Pin-Out An array of Pins (clusters containing the attributes of a
pin)
Control (ring) Type The type of signal connected in the pin among the
#9.2.1 groups: Transducers, Frequency Sensors, Power
Actuators, Frequency Actuators, Idle Speed Actuators,
On-Off Inputs, On-Off Outputs, Serial and Power &
- 144 -
Reference
Control (string) Name The name or relative path of the component associated
#9.2.2 with the pin
Control (u8) System Pin Number of the correspondent pin in the system
#9.2.3 connector
Control #9.3 (u8) Max Pins Number of pins at the ECU connector
Control #9.4 (string) Associated Contains the relative path of the user interface panel
Panel associated with this product
Control (cluster) ECU Out Std
#10
Control (string) Model The name to serve as a reference for the component in the
#10.1 Database
Control (array) Pin-Out An array of Pins (clusters containing the attributes of a
#10.2 pin)
Control (ring) Type The type of signal connected in the pin among the
#10.2.1 groups: Transducers, Frequency Sensors, Power
Actuators, Frequency Actuators, Idle Speed Actuators,
On-Off Inputs, On-Off Outputs, Serial and Power &
Reference
Control (string) Name The name or relative path of the component associated
#10.2.2 with the pin
Control (u8) System Pin Number of the correspondent pin in the system
#10.2.3 connector
Control (u8) Max Pins Number of pins at the ECU connector
#10.3
Control (string) Associated Contains the relative path of the user interface panel
#10.4 Panel associated with this product
Control (path) Database Base
#11 Path
Control (array) Pin-Out An array of Pins (clusters containing the attributes of a pin)
#12
Control (string) Name The name or relative path of the component associated
#12.1 with the pin
Control (u16) Type The type of signal connected in the pin
#12.2
Control (bool) Apertou
#12.3
Control (cluster) Pin A cluster containing the attributes of a pin
#13
Control (string) Name The name or relative path of the component associated
#13.1 with the pin
Control (u16) Type The type of signal connected in the pin
#13.2
Control (bool) Apertou
#13.3
Indicator (string) Model The name to serve as a reference for the component in the
#1 Database
Indicator (string) Associated Panel Contains the relative path of the user interface panel associated
#2 with this product
Indicator (cluster) ECU Out Std
#3
Indicator (string) Model The name to serve as a reference for the component in the
- 145 -
#3.1 Database
Indicator (array) Pin-Out An array of Pins (clusters containing the attributes of a
#3.2 pin)
Indicator (ring) Type The type of signal connected in the pin among the
#3.2.1 groups: Transducers, Frequency Sensors, Power
Actuators, Frequency Actuators, Idle Speed Actuators,
On-Off Inputs, On-Off Outputs, Serial and Power &
Reference
Indicator (string) Name The name or relative path of the component associated
#3.2.2 with the pin
Indicator (u8) System Pin Number of the correspondent pin in the system
#3.2.3 connector
Indicator (u8) Max Pins Number of pins at the ECU connector
#3.3
Indicator (string) Associated Contains the relative path of the user interface panel
#3.4 Panel associated with this product
Indicator (bool) Remove Product?
#4 (F)
PRODUCTS1.VI
Reference for other VIs of the data structure of a Product
Front Panel
Elements:
Indicator (cluster) ECU A cluster containing the registration atributes of an ECU
#1
Indicator (string) Model The name to serve as a reference for the component in the
#1.1 Database
Indicator (array) Pin-Out An array of Pins (clusters containing the attributes of a
#3.2 pin)
Indicator (ring) Type The type of signal connected in the pin among the
#1.2.1 groups: Transducers, Frequency Sensors, Power
Actuators, Frequency Actuators, Idle Speed Actuators,
On-Off Inputs, On-Off Outputs, Serial and Power &
Reference
Indicator (string) Name The name or relative path of the component associated
#1.2.2 with the pin
Indicator (u8) System Pin Number of the correspondent pin in the system
#1.2.3 connector
Indicator (u8) Max Pins Number of pins at the ECU connector
#1.3
Indicator (string) Associated Contains the relative path of the user interface panel
#1.4 Panel associated with this product
- 146 -
VTFITTIN.VI
Front Panel
Elements:
Control #1 (array) Input VT The Input Values Table to be processed. It receives the current
values in the attribute box of 'Cadastro.vi' but can be edited
before pressing the 'Go' button.
Control #2 (bool) Go to process the data in the Input VT.
Control #3 (dbl) Interval between The interval between samples, in physical units (1st column), in
Samples the Interpolated VT.
Control #4 (bool) Use Resistive Turn on to convert resistance values to voltage values in the
Divider (F) Interpolated Values Table, according to the Rup and Vcc values.
Control #5 (dbl) Rup Value (kW)
Control #6 (dbl) Vcc Value (V)
Control #7 (bool) Use Exponential Turn on to replace the original transfer function with that
Transfer Function evaluated by the Best Exponential Fit algorithm.
(F)
Control #8 (string) Current Input Trasfer Function as it comes from 'Cadastro.VI'.
Transfer Function
Indicator (array) Best Exp Fit VT
#1
Indicator (dbl) mean squared The mean squared error of the best exponential fit, in
#2 error comparison with the original set of data.
Indicator (array) Interpolated VT The Values Table after being processed by the spline
#3 interpolation on the Input VT and the resistance/voltage
convertion, if applicable.
Indicator (string) New Transfer Original or exponential transfer function evaluated as decided
#4 Function by the user.
Indicator (string) Exponential Transfer function evaluated by the Best Exponential Fit
#5 Transfer Function algorithm.
Nesta biblioteca tambm esto os seguintes VIs, que no sero apresentados aqui em
detalhe: EncodeECU.vi, CheckPin_Out.vi, CheckPin_Out1.vi, CLUSTCFG.VI, COMPNNTS.VI,
COMPOPS.VI, ConfigCluster.VI, PRODOPS.VI, PRODOPS1.VI e PRODUCTS.VI.
- 147 -
Na biblioteca Security.llb
Retype.VI
Front Panel
Elements:
Control #1 (string) Password
Control #2 (bool) Ok
Control #3 (bool) Ccl
Indicator (string) Retyped
#1 Password
UserID.VI
Front Panel
Elements:
Control #1 (cluster) User Properties A cluster containing the register information about the selected
user. It has the following fields:
Control #1.1 (string) Login Nickname chosen by the user
Control #1.2 (string) Password Password associated with the login
Control #1.3 (array) Privileges An array of Actors representing wich packages may be
used by the user. In the current version, AutoSEFI takes
in count only the privileges of the first Actor in the array.
Control (enum) Actor The possible roles the user can play with the system. A
#1.3.1 role is specified through the access permission to a
package of the system.
Control #1.4 (string) Name Full name of the user.
Control #2 (listbox) Users These are the currently registered users.
Control #3 (bool) exit Exits the User Manager
Control #4 (bool) remove Removes selected user.
Control #5 (bool) modify Modifies selected user
Control #6 (bool) add Adds new user
Control #7 (cluster) User Model A cluster containing the register information model for an user.
It has the following fields:
Control #7.1 (string) Login Nickname chosen by the user
Control #7.2 (string) Password Password associated with the login
Control #7.3 (array) Privileges An array of Actors representing wich packages may be
used by the user. In the current version, AutoSEFI takes
in count only the privileges of the first Actor in the array.
Control (enum) Actor The possible roles the user can play with the system. A
#7.3.1 role is specified through the access permission to a
package of the system.
Control #7.4 (string) Name Full name of the user.
Control #8 (bool) Just Added? Flag to indicate that the current user is a new one and thus, if
no complete information is provided, he should be expelled from
the Database in the Modify User State
- 148 -
Na biblioteca Simulation.llb
CheckStepPosit2.VI
Version for aquiring stepper through digitals
Front Panel Elements:
Control #1 (array) Data In
Control #1.1 (u32) pattern
Control #2 (i32) Iteration
Control #3 (cluster) Config Info
Control #3.1 (u32) SensorITaskID
Control #3.2 (u32) DigitalInputTaskID
Control #3.3 (u32) SensorIITaskID
Control #3.4 (u32) IdleSpeedTaskID
Control #3.5 (u32) ActuatorITaskID
Control #3.6 (u32) DigitalOutputTaskID
Control #3.7 (u32) ActuatorIITaskID
Control #3.8 (u32) TimingRefTaskID
Control #3.9 (cluster) Config error
Control #3.9.1 (bool) status
Control #3.9.2 (i32) code
Control #3.9.3 (string) source
Control #3.10 (dbl) ActuatorIIPar
Control #3.11 (u32) VbattTaskID
Control #3.12 (cluster) IdleSpeedPars
Control (dbl) Number of
#3.12.1 Steps
Control (array) Phase
#3.12.2 Sequence
Control #4 (i32) Reference In
Control #5 (bool) Read?
Indicator #1 (cluster) Stepper
Indicator #1.1 (array) Data
Indicator #1.2 (bool) Read?
Indicator #1.3 (i32) Last
Indicator #2 (array) Data Out
Indicator #3 (cluster) error out
Indicator #3.1 (bool) status
Indicator #3.2 (i32) code
Indicator #3.3 (string) source
Indicator #4 (i32) Reference Out
CTR Control2.VI
This VI controls and reads groups of counters. Control
operations include starting, stopping, and setting the output
state
Front Panel Elements:
- 149 -
CTR Group Config2.VI
This VI collects one or more counters into a group. Counter
groups containing more than one counter are useful for starting,
stopping, or reading multiple counters simultaneously. Multiple
counter groups are not currently supported by MIO-E Series
boards.
Front Panel Elements:
- 150 -
GET_PARS.VI
This Vi retrieves the information about the components of an
ECU from the Database, that are required for the configuration
of the DAQ boards
Front Panel Elements:
Control #1 (path) ECU Path The path of the ECU from which the information shall be
retrieved.
Control #2 (cluster) limit settings
Control #2.1 (sgl) high limit (10 V) specifies the maximum voltage the board measures
at a particular channel.
Control #2.2 (sgl) low limit (-10 V) specifies the minimum voltage the board measures
at a particular channel.
Control #2.3 (u16) reference source (no
change:0)
Control #3 (cluster) input limits an array of clusters, of which each array element specifies the
range limits for the channel(s) in the corresponding element of
the channels array. If there are fewer elements in this array
than the number of channels, the VI uses the last element for
the rest of the channels. The default input is an empty array,
which means the input limits do not change from their default
settings. Each cluster contains the following parameters:
Control #3.1 (sgl) high limit (10 V) specifies the maximum voltage the board measures
at a particular channel.
Control #3.2 (sgl) low limit (-10 V) specifies the minimum voltage the board measures
at a particular channel.
Control #4 (path) Database Base
Path
Indicator #1 (cluster) SensorI a cluster containing information for the Transducers
parameters simulation.
Indicator #1.1 (array) SensorI Port List Array of strings with the analog output channels to
be configured.
Indicator #1.2 (array) limit settings The signal limits and reference for each channel
(Output)
Indicator (cluster)
#1.2.1
Indicator (sgl) high limit
#1.2.1.1 (10 V)
Indicator (sgl) low limit (-
#1.2.1.2 10 V)
Indicator (u16) reference
#1.2.1.3 source (no
change:0)
Indicator #2 (cluster) SensorII a cluster containing information for the Frequency Sensors
parameters simulation.
Indicator #2.1 (array) SensorII Port List Array of strings with the analog output channels to
be configured.
Indicator #2.2 (array) limit settings The signal limits and reference for each channel
(Output)
Indicator (cluster)
#2.2.1
- 151 -
Indicator (sgl) high limit
#2.2.1.1 (10 V)
Indicator (sgl) low limit (-
#2.2.1.2 10 V)
Indicator (u16) reference
#2.2.1.3 source (no
change:0)
Indicator #3 (cluster) ActuatorI a cluster containing information for the Power Actuators
parameters acquisition.
Indicator #3.1 (array) ActuatorI Port List Array of strings with the analog input channels to be
configured.
Indicator #3.2 (array) input limits (Input) an array of clusters, of which each array element
specifies the range limits for the channel(s) in the
corresponding element of the channels array. If
there are fewer elements in this array than the
number of channels, the VI uses the last element for
the rest of the channels. The default input is an
empty array, which means the input limits do not
change from their default settings. Each cluster
contains the following parameters:
Indicator (cluster)
#3.2.1
Indicator (sgl) high limit specifies the maximum voltage the board measures at
#3.2.1.1 (10 V) a particular channel.
Indicator (sgl) low limit (- specifies the minimum voltage the board measures at
#3.2.1.2 10 V) a particular channel.
Indicator #4 (path) Associated Path of the interface panel associated with this ECU.
Panel
Indicator #5 (cluster) ActuatorII a cluster containing information for the Frequency Actuators
parameters acquisition.
Indicator #5.1 (array) Operating The operating frequencies for each actuator, used to
Frequencies configure the counter/timers and calculate duty cycles
Indicator (dbl) Operating
#5.1.1 Frequency
Indicator #6 (cluster) IdleSpeed
parameters
Indicator #6.1 (dbl) Number of
Steps/Op. Freq.
Indicator #6.2 (array) Forward Step Each pattern is a (u32)
Phase Sequence
My Error Handler.VI
This error handler is used primarily to inform the user if an
input error exists, to describe the error, and to identify where it
occurred. The information needed to do this is derived from the
inputs error cluster in, error code, and error source, and from
an internal error description table. The table lists all errors that
can be created by LabVIEW or its associated I/O operations.
Front Panel Elements:
- 152 -
POWERCFG2.VI
This VI configures the hardware and allocates a buffer for a buffered analog
input operation for a specified group of channels. Before performing any
configuration, AI Config checks to see if the input cluster error in indicates
that an error has already occurred. If so, then this VI does no
configuration, but passes the error information unmodified through error
out. In an error condition, taskID is 0. Otherwise, this VI calls several low-
level analog input VIs to set up a task for a buffered analog input
acquisition. AI Config calls Analog Input Group Config for the specified
device, group, and channels to create a taskID. AI Config then calls Analog
Input Hardware Config to record information about the hardware
configuration. The input limits input passes to Analog Input Hardware
Config, which sets up the lower and upper voltage limits for each channel;
if unspecified, the input limits do not change. This VI configures the
number of AMUX boards, the coupling used for each channel (that is, AC,
DC, ground, or internal reference), and the input configuration (differential,
referenced single-ended, or non-referenced single ended). You can use the
low-level Analog Input Hardware Config VI instead if you prefer to specify
the input signal range in terms of signal range, polarity, and gain. AI Config
configures the buffer for the acquisition by calling Analog Input Buffer
Config. Analog Input Buffer Config allocates memory for the specified
number of buffers (the default value is one), where each buffer contains
buffer size number of scans.
Front Panel Elements:
PulseMeas.VI
Measures the pulse width (length of time a signal is high or low) or period
(length time between adjacent rising or falling edges) of a TTL signal
connected to the counter's GATE pin. This VI is useful in measuring the
frequency of relatively low frequency signals; use the Measure Frequency VI
for relatively high frequency signals. The VI iterates until a valid
measurement, timeout, or counter overflow occurs. A valid measurements
exists when count is >= 4 without a counter overflow. If counter overflow
occurs, lower the timebase. If you start a pulse width measurement
during the phase you want to measure, you will get a short count.
Therefore, make sure the pulse does not occur until after the counter is
started. This restriction does not apply to period measurements.
The VI calls the Pulse Width or Period Meas Config, Counter Start, Counter
Read, and Counter Stop VIs.
Front Panel Elements:
- 153 -
PulseMeas2.VI
Measures the pulse width (length of time a signal is high or low) or period
(length time between adjacent rising or falling edges) of a TTL signal
connected to the counter's GATE pin. This VI is useful in measuring the
frequency of relatively low frequency signals; use the Measure Frequency VI
for relatively high frequency signals. The VI iterates until a valid
measurement, timeout, or counter overflow occurs. A valid measurements
exists when count is >= 4 without a counter overflow. If counter overflow
occurs, lower the timebase. If you start a pulse width measurement
during the phase you want to measure, you will get a short count.
Therefore, make sure the pulse does not occur until after the counter is
started. This restriction does not apply to period measurements.
The VI calls the Pulse Width or Period Meas Config, Counter Start, Counter
Read, and Counter Stop VIs.
Front Panel Elements:
PulseMeas2Config.VI
Configures the specified counter to measure the pulse width or period of a
TTL signal connected to its GATE pin. The measurement is done by
counting the number of cycles of the specified timebase between the
appropriate starting and ending events. To accurately measure pulse width,
the pulse must occur after the counter is started. Call Counter Start to
start the operation. You can also use this VI to measure the frequency of
low frequency signals.
Front Panel Elements:
PulseMeasConfig.VI
Configures the specified counter to measure the pulse width or period of a
TTL signal connected to its GATE pin. The measurement is done by
counting the number of cycles of the specified timebase between the
appropriate starting and ending events. To accurately measure pulse width,
the pulse must occur after the counter is started. Call Counter Start to
start the operation. You can also use this VI to measure the frequency of
low frequency signals.
Front Panel Elements:
- 154 -
RPMARRAY_3.VI
This VI generates the bidimensional array that contains the
values to be sent to the Output Buffer, in order to simulate the
desired RPM and Knock signals, according to the 8333,33
points/sec chosen update rate and the RPM values that can be
simulated with the current version of the system.
Front Panel Elements:
Control #1 (array) RPM A tridimensional array of (sgl) containing the
Patterns bidimensional arrays for each of the possible RPM
values, that could be sent to the Output Buffer, in
order to simulate the desired RPM signal.
Control #2 (array) Knock A bidimensional array of (dbl) containing the
Patterns singledimensional arrays for each of the possible
RPM values, that could be sent to the Output
Buffer, in order to simulate the desired Knock
signal.
Control #3 (bool) Setup?(F) If Setup is true, the VI prepares the tables with all
the available RPM and Knock Patterns, which
takes a long execution time.
Control #4 RPM The RPM value set by the user.
Control #5 (bool) Knock?(F) When True, the table Current RPM Pattern will
also contain Knock information to be simulated.
Indicator (array) Current An array of (dbl) containing the values to be sent to
#1 RPM Pattern the Output Buffer, in order to simulate the desired
RPM and Knock signals.
Indicator (i16) Actual RPM The RPM value that can be simulated and is the
#2 closest to the user selected RPM.
TRANSCFG.VI
This VI configures an analog output operation for a specified set of channels. This VI
records the hardware configuration and allocates a buffer for a buffered analog output
operation. Before performing any configuration, AO Config checks the input cluster
error in to determine whether an error has already occurred. If so, then this VI does no
configuration, but passes the error information modified through error out. In an error
condition, taskID is 0. Otherwise, this VI calls several low-level analog output VIs to set
up a task for a buffered analog output. AO Config calls Analog Output Group Config for
the specified device, group, and channels to create a taskID. AO Config then calls
Analog Output HW Config to record information about the hardware configuration. AO
Config configures the buffer for buffered waveform generation by calling Analog Output
Buffer Config. Analog Output Buffer Config allocates memory for the number of
updates specified by buffer size.
Front Panel Elements:
- 155 -
Runtest.VI
This VI performs an entire simulation on a product, from the
Tecnician identification, through the stimulus generation and
responses analisys and to the simulation report.
Front Panel Elements:
Control #1 (cluster) Config Info Contains all configuration information required to access the
DAQ boards.
Control #1.1 (u32) SensorITaskID Reference for AO operations regarding Transducers.
Control #1.2 (u32) DigitalInputTaskID
Control #1.3 (u32) SensorIITaskID Reference for AO operations regarding Frequency
Sensors.
Control #1.4 (u32) IdleSpeedTaskID Reference for counter operations regarding Idle
Speed Actuators.
Control #1.5 (u32) ActuatorITaskID Reference for AI operations regarding Power
Actuators.
Control #1.6 (u32) DigitalOutputTaskID
Control #1.7 (u32) ActuatorIITaskID Reference for AI operations regarding Frequency
Actuators.
Control #1.8 (u32) TimingRefTaskID
Control #1.9 (cluster) Config error
Control #1.9.1 (bool) status
Control #1.9.2 (i32) code
Control #1.9.3 (string) source
Control (dbl) ActuatorIIPar
#1.10
Control VbattTaskID
#1.11
Control (cluster) IdleSpeedPars
#1.12
Control (dbl) Number of
#1.12.1 Steps
Control (array) Phase
#1.12.2 Sequence
Control #2 (path) Database Base Specifies the base path where the Parts Database is stored.
Path
Control #3 (bool) Off
Control #4 (cluster) Panel Input Data
Control #4.1 (u32) Digital Inputs
Control #4.2 (dbl) Advance Angle
Control #4.3 (dbl) Dwell Angle
Control #4.4 (dbl) Cannister
Control #4.5 (u32) Stepper Motor
Control #4.6 (array) Injectors Array of (sgl)
Control #4.7 (dbl) Battery
Control #5 (bool) AIOk?
Indicator (bool) AllOk?
#1
Indicator (dbl) Cannister
#2
- 156 -
Indicator (bool) Fatal error
#3
Indicator (string) Panel Error
#4 message
Indicator (cluster) Panel Output
#5 Data
Indicator (bool) Panel Power
#5.1
Indicator (u32) Digital Outputs
#5.2
Indicator (array) Transducers Array of (sgl)
#5.3
Indicator (i8) Selected Power
#5.4 Actuator
Indicator (i16) RPM
#5.5
Indicator (bool) KNOCK
#5.6
Indicator (u16) Lambda Mode
#5.7
Indicator (i8) Trigger Adjust
#5.8
Indicator (i16) Actual RPM
#6
Indicator (string) Stepper Error
#7
Indicator (u32) Position
#8
Indicator (bool) End Test?
#9
Runtest2.VI
This VI performs an entire simulation on a product, from the
Tecnician identification, through the stimulus generation and
responses analisys and to the simulation report.
This version acquires the stepper signal through digitals.
Front Panel Elements:
Control #1 (cluster) Config Info Contains all configuration information required to access the
DAQ boards.
Control #1.1 (u32) SensorITaskID Reference for AO operations regarding Transducers.
Control #1.2 (u32) DigitalInputTaskID
Control #1.3 (u32) SensorIITaskID Reference for AO operations regarding Frequency
Sensors.
Control #1.4 (u32) IdleSpeedTaskID Reference for counter operations regarding Idle
Speed Actuators.
Control #1.5 (u32) ActuatorITaskID Reference for AI operations regarding Power
Actuators.
Control #1.6 (u32) DigitalOutputTaskID
- 157 -
Control #1.7 (u32) ActuatorIITaskID Reference for AI operations regarding Frequency
Actuators.
Control #1.8 (u32) TimingRefTaskID
Control #1.9 (cluster) Config error
Control #1.9.1 (bool) status
Control #1.9.2 (i32) code
Control #1.9.3 (string) source
Control (dbl) ActuatorIIPar
#1.10
Control VbattTaskID
#1.11
Control (cluster) IdleSpeedPars
#1.12
Control (dbl) Number of
#1.12.1 Steps
Control (array) Phase
#1.12.2 Sequence
Control #2 (enum) Initial State {Initialization, Configuration, Simulation, History, Error, Stop}
Control #3 (path) Database Base Specifies the base path where the Parts Database is stored.
Path
Control #4 (bool) Acquiring
Control #5 (bool) Off
Control #6 (cluster) Panel Input Data
Control #6.1 (u32) Digital Inputs
Control #6.2 (dbl) Advance Angle
Control #6.3 (dbl) Dwell Angle
Control #6.4 (dbl) Cannister
Control #6.5 (array) Stepper Motor Array of (u32)
Control #6.6 (array) Injectors Array of (sgl)
Control #6.7 (dbl) Battery
Control #7 (bool) Monitoring Only
Control #8 (bool) AIOk?
Indicator (bool) AllOk?
#1
Indicator (dbl) Cannister
#2
Indicator (dbl) Mark time
#3
Indicator (dbl) Period
#4
Indicator (bool) Fatal error
#5
Indicator (string) Panel Error
#6 message
Indicator (cluster) Stepper
#7
Indicator (array) Data Array of (u32)
#7.1
Indicator (bool) Read?
#7.2
Indicator (i32) Last
#7.3
- 158 -
Indicator (cluster) Panel Output
#8 Data
Indicator (bool) Panel Power
#8.1
Indicator (u32) Digital Outputs
#8.2
Indicator (array) Transducers Array of (sgl)
#8.3
Indicator (i8) Selected Power
#8.4 Actuator
Indicator (i16) RPM
#8.5
Indicator (bool) KNOCK
#8.6
Indicator (u16) Lambda Mode
#8.7
Indicator (i8) Trigger Adjust
#8.8
Indicator (i16) Actual RPM
#9
Nesta biblioteca tambm esto os seguintes VIs, que no sero apresentados aqui em
detalhe: Runtesttemp.vi, Interact.vi, CheckStepPosit.vi, Startup.vi e Transduce.vi.
- 159 -
Na biblioteca UserInterface.llb
Panel 1AVB76AT.VI
This VI ist the main HMI with the Technician.
Front Panel Elements:
Control #1 (i16) THROTTLE
[degree]
Control #2 (i16) RPM
Control #3 (i16) Air Pressure
(MAP) [mbar]
Control #4 (i16) Air Temp [C]
Control #5 (i16) H2O Temp [C]
Control #6 (bool) KNOCK
Control #7 (bool) Air Conditioning
Switch
Control #8 (bool) Key on
Control #9 (sgl) Oxygen Control
Control (cluster) Panel Input Data
#10
Control (u32) Digital Inputs
#10.1
Control (dbl) Advance Angle
#10.2
Control (dbl) Dwell Angle
#10.3
Control (dbl) Cannister
#10.4
Control (u32) Stepper Motor
#10.5
Control (array) Injectors Array of (sgl)
#10.6
Control (dbl) Battery
#10.7
Control (bool) Setup Panel?
#11
Control (path) Panel Config File
#12 Path
Control (i16) Temporary max
#13 step number
Control (bool) Hold Output
#14
Control (bool) Run Scipt
#15
Control (bool) Inj 1
#16
Control (bool) Inj 2
#17
Control (bool) Inj 3
#18
Control (bool) Inj 4
#19
- 160 -
Control (u8) Injectors Choice
#20
Control (i8) Trig Adj
#21
Control (bool) Wired Air Pressure (MAP)
#22
Control (bool) Wired Air Temp
#23
Control (bool) Wired H2O Temp
#24
Control (bool) Wired THROTTLE
#25
Control (bool) Wired KNOCK
#26
Control (bool) Wired RPM
#27
Control (bool) Information
#28
Control (bool) Power
#29
Control (u16) Mode
#30
Control (bool) RPM Up
#31
Control (bool) RPM Down
#32
Control (bool) Show Ignition(F)
#33
Indicator (sgl) Advance Angle
#1
Indicator (bool) Air Conditioning
#2 Relay
Indicator (u32) Stepper Motor
#3
Indicator (array) Fuel Injectors Array of (sgl)
#4 1,2,3 and 4 (A x
ms)
Indicator (array) Oxygen Sensor Array of (sgl)
#5
Indicator (cluster) Panel Output
#6 Data
Indicator (bool) Panel Power
#6.1
Indicator (u32) Digital Outputs
#6.2
Indicator (array) Transducers Array of (sgl)
#6.3
Indicator (i8) Selected Power
#6.4 Actuator
Indicator (i16) RPM
#6.5
- 161 -
Indicator (bool) KNOCK
#6.6
Indicator (u16) Lambda Mode
#6.7
Indicator (i8) Trigger Adjust
#6.8
Indicator (bool) Fatal error
#7
Indicator (string) Error message
#8
Indicator (array) Transducers Data
#9
Indicator (cluste
#9.1 r)
Indicator (u16) Sensor Type
#9.1.1
Indicator (array) Values Array Array of (dbl)
#9.1.2 1
Indicator (array) Values Array Array of (dbl)
#9.1.3 2
Indicator (dbl) Max Value
#9.1.4
Indicator (dbl) Min Value
#9.1.5
Indicator (array) Actuators II Data
#10
Indicator (cluste
#10.1 r)
Indicator (u16) Actuator Type
#10.1.1
Indicator (array) Values Array Array of (dbl)
#10.1.2 1
Indicator (array) Values Array Array of (dbl)
#10.1.3 2
Indicator (dbl) Max Value
#10.1.4
Indicator (dbl) Min Value
#10.1.5
Indicator (cluster) Idle Speed Data
#11
Indicator (u16) Control Type
#11.1
Indicator (array) Forward Step Phase Array of (u8)
#11.2 Sequence
Indicator (sgl) Battery [V]
#12
Indicator (bool) Pump
#13
Indicator (bool) Power Latch
#14
Indicator (sgl) Cannister (SLPM)
#15
- 162 -
Panel 1AVB76AT_3.VI
This VI ist the main HMI with the Technician.
Front Panel Elements:
Control #1 (i16) THROTTLE
[degree]
Control #2 (i16) RPM
Control #3 (i16) Air Pressure
(MAP) [mbar]
Control #4 (i16) Air Temp [C]
Control #5 (i16) H2O Temp [C]
Control #6 (bool) KNOCK
Control #7 (bool) Air Conditioning
Switch
Control #8 (bool) Key on
Control #9 (sgl) Oxygen Control
Control (cluster) Panel Input Data
#10
Control (u32) Digital Inputs
#10.1
Control (dbl) Advance Angle
#10.2
Control (dbl) Dwell Angle
#10.3
Control (dbl) Cannister
#10.4
Control (u32) Stepper Motor
#10.5
Control (array) Injectors Array of (sgl)
#10.6
Control (dbl) Battery
#10.7
Control (bool) Setup Panel?
#11
Control (path) Panel Config File
#12 Path
Control (i16) Temporary max
#13 step number
Control (bool) Hold Output
#14
Control (bool) Run Scipt
#15
Control (bool) Inj 1
#16
Control (bool) Inj 2
#17
Control (bool) Inj 3
#18
Control (bool) Inj 4
#19
- 163 -
Control (u8) Injectors Choice
#20
Control (i8) Trig Adj
#21
Control (bool) Wired Air Pressure (MAP)
#22
Control (bool) Wired Air Temp
#23
Control (bool) Wired H2O Temp
#24
Control (bool) Wired THROTTLE
#25
Control (bool) Wired KNOCK
#26
Control (bool) Wired RPM
#27
Control (bool) Information
#28
Control (bool) Power
#29
Control (u16) Mode
#30
Control (bool) RPM Up
#31
Control (bool) RPM Down
#32
Control (bool) Show Ignition(F)
#33
Indicator (sgl) Advance Angle
#1
Indicator (bool) Air Conditioning
#2 Relay
Indicator (u32) Stepper Motor
#3
Indicator (array) Fuel Injectors Array of (sgl)
#4 1,2,3 and 4 (A x
ms)
Indicator (array) Oxygen Sensor Array of (sgl)
#5
Indicator (cluster) Panel Output
#6 Data
Indicator (bool) Panel Power
#6.1
Indicator (u32) Digital Outputs
#6.2
Indicator (array) Transducers Array of (sgl)
#6.3
Indicator (i8) Selected Power
#6.4 Actuator
Indicator (i16) RPM
#6.5
- 164 -
Indicator (bool) KNOCK
#6.6
Indicator (u16) Lambda Mode
#6.7
Indicator (i8) Trigger Adjust
#6.8
Indicator (bool) Fatal error
#7
Indicator (string) Error message
#8
Indicator (array) Transducers Data
#9
Indicator (cluste
#9.1 r)
Indicator (u16) Sensor Type
#9.1.1
Indicator (array) Values Array Array of (dbl)
#9.1.2 1
Indicator (array) Values Array Array of (dbl)
#9.1.3 2
Indicator (dbl) Max Value
#9.1.4
Indicator (dbl) Min Value
#9.1.5
Indicator (array) Actuators II Data
#10
Indicator (cluste
#10.1 r)
Indicator (u16) Actuator Type
#10.1.1
Indicator (array) Values Array Array of (dbl)
#10.1.2 1
Indicator (array) Values Array Array of (dbl)
#10.1.3 2
Indicator (dbl) Max Value
#10.1.4
Indicator (dbl) Min Value
#10.1.5
Indicator (cluster) Idle Speed Data
#11
Indicator (u16) Control Type
#11.1
Indicator (array) Forward Step Phase Array of (u8)
#11.2 Sequence
Indicator (sgl) Battery [V]
#12
Indicator (bool) Pump
#13
Indicator (bool) Power Latch
#14
Indicator (sgl) Cannister (SLPM)
#15
- 165 -
Panel GetConfig.VI
Nesta biblioteca tambm esto os seguintes VIs, que no sero apresentados aqui em
detalhe: Panel OutValueFromTable.vi, Panel StepperMotorCalculator.vi e ZrO2 Capone.vi.
- 166 -