VEMS Home Products Documentation Wiki Webstore
WikiHome ProjectPage DocsPage UnderDevelopment MembersPage SiteIndex RecentChanges Preferences
MembersPage/GunnarReynisson/AdvancedVEMS

Eventually VEMS will release new and more advanced hardware, hardware I think the current VEMSTune implementation wouldn´t be able to handle properly.

See linked PDF for my notes on organizing complex ECUs into more easily manageable user experience and user interface.

http://www.vems.hu/files/VemsTune/VEMS%20Advanced.pdf

I don´t think everything in that document needs to be exactly as it is there, but by following similar construct a more advanced VEMS can make itself more user friendly and more easily supported.

If you want any information on anything in Pectel ECUs let me know. I can provide screenshots of anything requested.

Consideratiosn about input and outputs for future VEMS

I think for maximum versatility and future proofing the base of the VEMS ECU should be so that each input or output selectable should be detached from a physical input pin, this allows for instance CAN channels(or other protocols) to act as analog/digital inputs, as would outputs be (apart from ignition/injection outputs unless the receiver has live crank angle measurements at its disposal).

This could be described as base software and application software layers in where the application software layer only deals in the mathematics and logics while the base software only deals in converting physical pin values and stream protocol values into engineering values to be put into the two layers interface.

Example Fuel injection pulswewidth direct to pin

Application software sends the value to the base software as Cyl1_Pw

additionally the injection angle is also sent seperately as Cyl1_Angle

  • Inputs are Cyl1_Pw = 6.3ms
  • Cyl_Angle = 360°

Other inputs are

  • Cyl 1 Injector = Pin 8 - In Base Software side

BaseSw takes care of WHEN to start pulling the injector circuit down and when to stop given that it knows the crank angle etc.

Boost control 2 methods

Method 1 & 2

Method 1

Base Sw :

Boost output is set as a physical pin, BaseSw calculates timing and actions the pin accordingly

Method 2

Base Sw :

Boost output is set as CAN out -

CAN Id = 0x45, 16Bit size, Byte 0-1, gain 0.01%/bit , offset = 0

Can message byte 0-1 is sent as 4000 >> 0000 1111 1010 0000

Whoever is the receiver will handle the rest from there.

Inputs

In the App Sw the values are just a engineering value and so the software is written entirely on engineering values and boolean logic

The App Sw wouldn´t need to care where the value comes from.

Base software acts as the source of all the analog channels to the app software.

I believe this methododoloy also allows faster updates to control strategies in the App Sw as the interface between the AppSw and BaseSw is already in place and might not need updating everytime there is an App Sw update. This also allows a big interface to be constructed between the two before some channels are even being used like, i.e. fuel injector gauge pressure doesn´t need to be used, but the "fuel injector gauge SENSOR" is constructed from the start and will therefor always be available.

V4 FW requirements based on review of current V3 1.2.43 FW - Gunni

Time to put the V in versatile engine management to work!

  • Deadtime 3d table
  • Battery voltage vs delta fuel pressure (delta fuel pressure can be an assumed fixed number if no sensor is fitted), Z is milliseconds
  • Get rid of Traditional entirely.
  • Fuel density table required
  • 3d table with ethanol content vs fuel temperature, Z is grams per liter
  • Fuel stoichometric curve required
  • 2d table with ethanol content as the X axis. Z is AFR
  • If the vehicle runs on non petrol or ethanol based fuel something like methanol or a proportion of methanol coming out of the main injectors, the appropriate stoichometric value should still be put into the stoich curve and fuel density put into the fuel density table.
  • In essence convert the fuel model to mass based.
  • Air mass being - Air volume (VE * RPM ) * Air density (Air intake temp/Charge temp)
  • Fuel mass being - Fuel volume (( Inj opening time ) * Fuel pressure delta(MAP vs Fuel system pressure) ) * Fuel density (Fuel temp)
  • Cylinder fuel trim
  • 3d table for each injector cylinder output (only enabled if injector output is being used as an injector output), Z is % multiplier
  • Y axis - TPS, MAP, LOAD or whatever the user wants)
  • X axis - RPM usually or whatever the user wants
  • This means additive trim is not needed
  • Injector angle curve
  • 3d table 1
  • Y axis - TPS, MAP, LOAD or whatever the user wants)
  • X axis - RPM usually or whatever the user wants
  • This is because transport time is related to air velocity and so the same angle for every load for a single rpm point is not accurate.
  • 3d table 2 - can be used for angle trim based on whatever the users wants vs whatever the user wants (coolant temp, air temp, etc)
  • Angle table 1 + Angle table 2 = Z = final end of injection angle in BTDC
  • Injector staging
  • Complete copy of normal injector settings Deadtimes, Injector trims, Injector angle curve, injector output visual secondary, fuel density, fuel stoichometric curve etc
  • 3d table with usually MAP x RPM or whatever the user wants, Z is the value of total injection amount of the primary injectors in %.
  • Example :
  • Main fuel table requires 1000cc/min per injector flow at Y load and X RPM, but the main injectors would require 150% open time(they are 666cc/min).
  • This table can allow the secondary injectors to flow anywhere between 0-100%.
  • If the secondary injectors are for instance also 666cc/min then 50% in the table would open each injector 50% of the required total fuel flow
  • This would be 150*0.5=75% per injector in this example.
  • At 60% in the table would make the secondary injectors open for 90% and the primary injectors 60% (60+90=150%)
  • This is of course changes with differently sized injectors or the different type of fuel coming from the secondary injectors.
  • When the fuel and fuel injectors settings are correct for both primary and secondary then any % change in the 3d table should yield the same lambda.
  • The reasons to lean more on the seconary injectors can be to lean more on the secondary fuel type ( water methanol injection, methanol injection, ethanol, gas injection etc)
  • Cyl seperated spark delay
  • 3d table for each cylinder of usually Y is TPS, MAP or LOAD and X is rpm , Z is ignition advance delta
  • Step size can be removed
  • Speed limit (PID )
  • 3d table for each term
  • P table usually Y is TPS, MAP or whatever the user wants and X is Lambda error, Z is % of instant fuel change
  • I Table usually Y is TPS, MAP or whatever the user wants and X is Lambda error, Z is the % of change to add to the current I term
  • D Table usually Y is Rate of lambda error and X is lambda error. Z is the % of instance fuel change
  • I terms needs maximum and minimum allowed limits like idle control in 3d tables , Y as TPS, MAP or LOAD or whatever the users wants, X is RPM, Z for maximum limit represented as a positive value in it?s table, Z for minimum limit represented as a negative value in it?s table
  • No need for dynamic speed or assymetric speed with the above changes.
  • Vbatt compensation is a curve and not a single factor, X axis is VBAT, Z is % multiplier to the strategy normal output
  • PID settings
  • Tables for each term, like lambda control above. straight linear PID terms are not enough for best possible control.
  • P table ideally is Y is current TPS position , X is DBW target error
  • Inputs can be removed and internalized based on sensor setup menu , no need to double up selection points.
  • Safety output also internalized as it?s now inside the ECU vs V3
  • Other safety features required are thresholds for determining one of the TPS or PPS inputs has failed and DBW H-bridge must be shut down.
  • 3d table for fadeout time Y as TPS, MAP or user selected, X axis is coolant temp, Z is cycles
  • 3d table for Acc cold mult factor, Y as TPS, MAP or user selected, X axis is coolant temp, Z is % fuel multiplier
  • 3d table for Cold accel added amount, Y as TPS, MAP or user selected, X axis is coolant temp, Z is % fuel multiplier
  • 3d table for ign retard Y can be TPS, MAP or user selected, usually related to the amount of Accel enrichment, Z is % fuel multiplier
  • 3d table for d/TPS vs RPM , negative d/TPS available
  • 3d table for d/MAP vs RPM , negative d/MAP available
  • Integral limits need 3d tables, Y is run time/cycle since start or whatever the user wants, X is RPM, Z is IAC% MIN or MAX currently allowed
  • PID settings
  • Same as everything else so far
  • P table usually Y is TPS, MAP or whatever the user wants and X is Target error, Z is % BOOST DC% TRIM
  • I Table usually Y is TPS, MAP or whatever the user wants and X is Target error, Z is the % of change to add to the current I term, I term is % BOOST DC% TRIM
  • D Table usually Y is Rate of Target error and X is target error. Z is % BOOST DC% TRIM
  • These tables take over the PD control, PI Control, PID overlap range and the PID factors.
  • For direct output PWM Anytrim Control 1 , the Duty cycle and Frequency can be fixed elements or come from other Anytrim Control or Anytrim Math or Realtime channel sources
  • Example 1 : Closed loop PWM output with varying duty cycle (Base 3d table Z + PID loop Z) but frequency is fixed to Boost output frequency or RPM or from Anytrim Control 2
  • Example 2 : Closed loop PWM output with varying frequency , but duty cycle is fixed to Injector 1 DC% or Boost DC% or IAC% DC or Anytrim Control 2
Send us some V4 ECUs and we can all get to work