Platform Requirements

Hardware Requirements

Software Requirements

Installation Options

VECTO is distributed as a portable application. This means you can simply unzip the archive and directly start VECTO.exe. This, however, requires write and execute permissions for the VECTO application directory.

In case you do not have execute permissions, please ask your system administrator to install VECTO into an appropriate directory (e.g. under C:\Program Files). Installing VECTO requires the following two steps:

If the ExecutionMode is set to install (this is also possible when running VECTO from an arbitrary directory), VECTO does not write its configuration files and log files to the application directory but to the directories %APPDATA% and %LOCALAPPDATA% (usually C:\Users\<username>\AppData\Roaming and C:\Users\<username>\AppData\Local).

Important: If VECTO is run from a directory without write permissions it is necessary that you copy the generic VECTO models distributed with VECTO to a location where you have write permissions or set the output path to a directory with write permissions (see the Options in the main window).

User Manual



Version: VECTO 3.3 / VectoCore 3.3.2 / VectoCmd 3.3.2


VECTO is a tool for the calculation of energy consumption and CO2 emissions of vehicles. It models the components of a heavy-duty vehicle and simulates a virtual drive on a route. The goal is to provide a standardized way of calculating the energy consumption (fuel consumption) and corresponding CO2 emissions.

This User Manual consists of 4 Parts:

This user manual describes verson 3.3.x of Vecto.

User Interface

When VECTO starts the Main Form is loaded. Closing this form will close VECTO even if other dialogs are still open.

Main Form

Description

The Main Form is loaded when starting VECTO. Closing this form will close VECTO even if other dialogs are still open. In this form all global settings can be controlled and all other application dialogs can be opened.

In order to start a simulation the Calculation Mode must be set and at least one Job File (.vecto) must added to the Job List. After clicking START all checked files in the Job List will be calculated.

The Main Form includes two tabs as described below:

  • Job Files Tab
  • Options Tab

Job Files Tab

Job Files List

Job files (.vecto) listed here will be used for calculation. Unchecked files will be ignored! Doubleclick entries to edit job files with the VECTO Editor.

cb All
(Un-)Check all files in Job List. Only checked files are calculated when clicking START.

add Add files to Job List

remove Remove selected files from List

updown Move selected files up or down in list

List Options
  • Save/Load List
    • Save or load Job List to text file
  • Load Autosave-List
    • The Autosave-List is saved automatically on application exit and calculation start
  • Clear List
    • Remove all files from Job List
  • Remove Paths
    • Remove paths, i.e. only file names remain using the Working Directory as source path.

START START Button

Start VECTO in the selected mode (see Options).

Options Tab

In this tab the global calculation settings can be changed.

Mode

Select either Declaration Mode or Engineering Mode

Output Directory

This input can be used to write all simulation result files to a certain directory. This can be either an absolute path or a relative path. If an absolute path is provided, all result files are written to this directory. If a relative path is provided the .vmod and XML reports are written into the corresponding subdirectory of the job file and the .vsum file is written to the corresponding subdirectory of the first selected job file.

Output

cb Write modal results
Toggle output of modal results (.vmod files) in declaration mode. A Summary file (.vsum) is always created.
cb Modal results in 1Hz
If selected, the modal results (.vmod file) will be converted into 1Hz after the simulation. This may add certain artefacts in the resulting modal results file.

MISC

Validate Data
Enables or disables internal checks if the model parameters are within a reasonable range. When simulating a new vehicle model it is good to have this option enabled. If the model parameters are from certified components or the model data has only been modified slightly this check may be disabled. The VECTO simulation will abort anyways if there is an error in the model parameters. Enabling this option increases the simulation time by a few seconds.
Output values in vmod at beginning and end of simulation iterval
By default VECTO writes the simulation results at the middle of every simulation interval. If this option is enabled, the .vmod file will contain two entries for every simulation interval, one at the beginning and one at the end of the simulation interval. Enabling this option may be helpful for analysing the trace of certain signals but can not be used for quantitative analyses of the fuel consumption, average power losses, etc. The generated modal result file has the suffix ’_sim’. The picture below shows the difference in the output (top: conventional, bottom: if this option is checked)
Regular VECTO .vmod output (top) vs. beginning and end of simulation interval (bottom)

Controls

new New Job File
Create a new .vecto file using the VECTO Editor
open Open existing Job or Input File
Open an existing input file (Job, Engine, etc.)

tools Tools

info Help

  • User Manual
    • Opens this User Manual
  • Release Notes
    • Open the Release Notes (pdf)
  • Report Bug via CITnet / JIRA
    • Open the CITnet/JIRA website for reporting bug
  • Create Activation File
    • Create an Activation File used for Licensing
  • About VECTO
    • Information about the software, license and support contact
Message List
All messages, warnings and errors are displayed here and written to the log file LOG.txt in the VECTO application folder. Depending on the colour the following message types are displayed:
  • Status Messages
  • Warnings
  • Errors
  • Links - click to open file/user manual/etc.

Note that the message log can be opened in the Tools menu with Open Log.

In addition to the log messages shown in the message list, Vecto writes more elaborate messages in the subdirectory logs. If multiple simulations are run in parallel (e.g., in declartion mode a vehicle is simulated on different cycles with different loadings) a separate log-file is created for every simulation run.

Statusbar
Displays current status and progress of active simulations. When no simulation is executed the current mode is displayed (Engineering or Declaration Mode).

Settings

Description

In the Settings dialog controls general application settings. The settings are saved in the settings.json file.

Interface Settings

File Open Command
This command will be used to open CSV Input Files like Driving Cycles (.vdri). See: Run command
Name: Name of the command as it will be shown in the menu when clicking the button.
Command: The actual command.

Example : If the command is excel and the file is C:\VECTO\cycle1.vdri then VECTO will run: excel “C:\VECTO\cycle1.vdri”

Calculation Settings

Air Density [kg/m³]
The Air Density is needed to calculate the air resistance together with the Drag Coefficient and the Cross Sectional Area (see Vehicle Editor).

This setting is only used in Engineering mode. In Declaration mode the default value of 1.188 [kg/m³] is used.

Controls

Reset All Settings
All values in the Settings dialog and Options Tab of the Main Form will be restored to default values.

Save and close dialog

Close without saving

Job Editor

Description

The job file (.vecto) includes all informations to run a VECTO calculation. It defines the vehicle and the driving cycle(s) to be used for calculation. In summary it defines:

  • Filepath to the Vehicle File (.vveh) which defines the not-engine/gearbox-related vehicle parameters
  • Filepath to the Engine File (.veng) which includes full load curve(s) and the fuel consumption map
  • Filepath to the Gearbox File (.vgbx) which defines gear ratios and transmission losses
  • Filepath to the Gearshift Parameters File (.vtcu) which allows to override parameters of the Effshift Gearshift Strategy. The gearshift parameters cannot be edited via the graphical user interface. In case the default parameters shall be used either an empty .vtcu file (see .vtcu) or the gearbox file (.vgbx) can be provided. An example .vtcu file is provided here
  • Auxiliaries
  • Driver Assist parameters
  • Driving Cycles (only in Engineering Mode)

Relative File Paths

It is recommended to use relative filepaths. This way the Job File and all input files can be moved without having to update the paths. Example: “Vehicles\Vehicle1.vveh” points to the “Vehicles” subdirectory of the Job File’s directoy.

VECTO automatically uses relative paths if the input file (e.g. Vehicle File) is in the same directory as the Job File. (Note: The Job File must be saved before browsing for input files.)

General Settings

Engine Only Mode

Enables Engine Only Mode (Engineering mode only). The following parameters are needed for this mode:

Filepath to the Vehicle File (.vveh)
Files can be created and edited using the Vehicle Editor.
Filepath to the Engine File (.veng)
Files can be created and edited using the Engine Editor.
Filepath ot the Gearbox File(.vgbx)
Files can be created and edited using the Gearbox Editor.

Filepath ot the Shift Parameters File(.vtcu)

Filepath ot the Hybrid Strategy Parameters File(.vhctl)
Files can be created and edited using the Hybrid Strategy Parameters Editor.

Auxiliaries Tab

Auxiliaries
This group contains input elements to define the engine’s load from the auxiliaries. In Declaration Mode only the pre-defined auxiliaries are available and their power-demand is also pre-defined, depending on the vehicle category and driving cycle. The list contains the pre-defined auxiliaries where the concrete technology for each auxiliary can be configured using the Auxiliary Dialog. Double-click entries to edit with the Auxiliary Dialog. No other types of auxiliaries can be used in declaration mode.
Auxiliaries
In Engineering Mode the auxiliary power demand can be defined in three ways.

The first option is to define the power demand directly in the driving cycle in the column “Padd” (see Driving Cycles. This allows to vary the auxiliary load over distance (or time, for time-based driving cycles).

The second option is to define a constant power demand over the whole cycle. The auxiliary power demand can be specified depending on whether the combustion engine is on or off and the vehicle is driving. The auxiliary power demand during engine-off phase is corrected in the post-processing.

The third option is to use the bus-auxiliaries model. For details see the Bus Auxiliaries model.

See Auxiliaries for details.

Cycles Tab

Cycles
List of cycles used for calculation. The .vdri format is described here.

In Declaration Mode, the cycles to be simulated depend on the vehicle group. The cycles are listed in this window for reference.

In Engineering Mode the cycles can be freely selected. All declaration cycles are provided in the Folder “Mission Profiles” and can be used or a custom cycle can be created and used.

Double-click an entry to open the file (see File Open Command).

Click selected items to edit file paths.
addcycle Add cycle (.vdri)
remcycle Remove the selected cycle from the list

Driver Assist Tab

In this tab the driver assistance functions are enabled and parameterised. The parameters for overspeed, look-ahead coasting and driver acceleration can only be modified in Engineering Mode.

Overspeed
See Overspeed for details.
Look-Ahead Coasting
See Look-Ahead Coasting for details.
Acceleration Limiting
See Acceleration Limiting for details.

ADAS Parameters

In this tab certain general parameters for the advanced driver assistant system model can be set. Which ADAS feature is available can be selected in the vehicle itself, in Engineering Mode parameters like minimum activation speed, activation delay, or allowed overspeed can be adjusted. In Declaration Mode all parameters are fixed.

For details on the individual parameters see the corresponding section Engine Stop/Start, Eco-Roll, Predictive Cruise Control

Chart Area

The chart area on the right shows the main vehicle parameters like HDV group and axle configuration if a valid Vehicle File, Engine File and Gearbox File is loaded into the Editor. The plot shows the full load curve(s) and sampling points of the fuel consumption map.

Controls

new New Job File
Create a new empty .vecto file
open Open existing Job File
Open an existing .vecto file

save Save current Job File

SaveAs Save Job File as…

sendto Send current file to Job List in Main Form
Note: The file will be sent to the Job List automatically when saved.

veh Open Vehicle Editor

eng Open Engine Editor

gbx Open Gearbox Editor

Browse for vehicle/engine/gearbox files

OK Save and close file
File will be added to Job List in the Main Form.

Cancel Cancel without saving

VTP-Job Editor

Description

A VTP-Job is intended to verify the declared data of a vehicle through an on-road test. VTP-Jobs can be either simulated in engineering mode or declaration mode. For a VTP simulation the measured driving cycle along with the VECTO job-file is required. The driving cycle has to contain the vehicle’s velocity, rotational speed of the driven wheels, torque of the driven wheels, and fuel consumption in a temporal resolution of 2Hz.

VECTO computes the best matching gear based on the vehicle parameters, the actual vehicle speed and the engine speed. Next, VECTO re-computes the fuel consumption based for the given driving cycle. For a VTP-test the re-computed fuel consumption has to be within certain limits of the real fuel consumption.

The VTP job file (.vecto) includes all informations to run a VECTO calculation. It defines the vehicle and the driving cycle(s) to be used for calculation. In summary it defines:

  • Filepath to the Vehicle File (.xml) which defines all relevant parameters, including all components
  • Driving Cycles

In engineering mode multiple driving cycles can be specified

In declaration mode only the first given driving cycle is simulated as the results are further compared with the re-simulated results of the reference cycle. The reference cycle is the first driving cycle applicable for the actual vehicle group as listed in the Job Window and provided in the reports (i.e., LongHaul for most heavy lorries).

In declaration mode the manufacturer’s record file needs to be provided. Furthermore, declaration mode simulations consider correction factors for the net calorific value of the used fuel and the vehicle’s mileage. In engineering mode the according input fields are not shown.

Relative File Paths

It is recommended to use relative filepaths. This way the Job File and all input files can be moved without having to update the paths. Example: “Vehicles\Vehicle1.xml” points to the “Vehicles” subdirectory of the Job File’s directoy.

VECTO automatically uses relative paths if the input file (e.g. Vehicle File) is in the same directory as the Job File. (Note: The Job File must be saved before browsing for input files.)

Cycles
List of cycles used for calculation. The .vdri format is described here. Double-click an entry to open the file (see File Open Command). Click selected items to edit file paths.

addcycle Add cycle (.vdri)

remcycle Remove the selected cycle from the list

Chart Area

The chart area on the right shows the main vehicle parameters like HDV group and axle configuration if a valid Vehicle File is loaded into the Editor. The plot shows the full load curve(s) and sampling points of the fuel consumption map.

Controls

new New Job File
Create a new empty .vecto file
open Open existing Job File
Open an existing .vecto file

save Save current Job File

SaveAs Save Job File as…

sendto Send current file to Job List in Main Form
Note: The file will be sent to the Job List automatically when saved.

Browse for vehicle file

OK Save and close file
File will be added to Job List in the Main Form.

Cancel Cancel without saving

Auxiliary Dialog

Auxiliary Dialog (Declaration Mode)

Description

The Auxiliary Dialog is used to configure auxiliaries. In Declaration Mode the set of auxiliaries and their power demand is pre-defined. For every auxiliary the user has to select the technology from a given list.

Settings

Technology
List of available technology for the auxiliary type For the steering pump multiple technologies can be defined, one for each steered axle.

Controls

ok Save and close

cancel Close without saving

In Engineering Mode the auxiliary power demand can either be specified in the driving cycle over distance (or time), specified as constant load, or via the bus auxiliaires. For more details see the Auxiliaries tab in the Job editor.

BusAuxiliary Dialog

In Engineering Mode the electrical and mechanical power demand for the electric system, the pneumatic system and the HVAC can be provided.

Electric System

Current Demand Engine On
Demand of the electric system when the ICE is on. The current is multiplied with the nominal voltage of 28.3V.
Current Demand Engine Off Driving
Demand of the electric system when the ICE is off and the vehicle is driving. The current is multiplied with the nominal voltage of 28.3V.
Current Demand Engine Off Standstill
Demand of the electric system when the ICE is off and the vehicle is at standstill. The current is multiplied with the nominal voltage of 28.3V.
Alternator Efficiency
The electric power demand is divided by the alternator efficiency to get the mechanical power demand at the crank shaft
Alternator Technology
The “conventional alternator” generated exactly the electric power as demanded by the auxiliaries. The “smart alternator” may generate more electric power than needed during braking phases. The exessive electric power is stored in a battery. In case “no alternator” is selected (only available for xEV vehicles) the electric system is supplied from the high voltage REESS via a DC/DC converter.
Max Recuperation Power
In case of a smart alternator, defines the maximum electric power the alternator can generate during braking phases.
Useable Electric Storage Capacity
In case of a smart alternator, defines the storage capacity of the battery. In case the battery is not empty, the electric auxiliaries are supplied from the battery. Excessive electric energy from the smart alternator during braking phases is stored in the battery.
Electric Storage Efficiency
This efficiency is applied when storing electric energy from the alternator in the battery.
ESS supply from HEV REESS
If selected, the low-voltage electric auxiliaries can be supplied from the high voltage REESS via the DC/DC converter. Needs to be selected in case “no alternator” is chosen as alternator technology. In case of a smart alternator, the low-voltage battery is used first and if empty the energy is drawn from the high voltage system.

Pneumatic System

Compressor Map
Compressor map file defining the mechanical power demand and the air flow depending on the compressor speed.
Average Air Demand
Defines the average demand of copressed air througout the cycle.
Compressor Ratio
Defines the ratio between the air compressor and combustio engine
Smart Air Compressor
If enabled, the air compressor may generate excessive air during braking events. The air consumed and generated are corrected in post processing.

HVAC System

Mechanical Power Demand
Power demand of the HVAC system directly applied at the crank shaft
Electric Power Demand
Electric power demand of the HVAC system. This is added to the current demand of the electric system
Aux Heater Power
Maximum power of the auxiliary heater
Average Heating Demand
Heating demand for the passenger compartment. This demand is primary satisfied from the combustion engines waste heat. In case the heating demand is higher, the auxiliary heater may provide additional heating power. The fuel consumption of the aux heater is corrected in post processing.

Vehicle Editor – General Tab

Description

The Vehicle File (.vveh) defines the main vehicle/chassis parameters like axles including RRCs, air resistance and masses.

The Vehicle Editor contains up to 6 tabs, depending on the powertrain architecture and simulation mode, to edit all vehicle-related parameters. The ‘General’ tab allows to input mass, loading, air resistance, vehicle axles, etc. The ‘Powertrain’ tab allows to define the retarder, an optional angle drive. The third tab is dedicated to all electric components in case of hybrid electric and battery electric vehicles. In the fourth tab the torque limitations for the combustion engine, the electric motor and the whole vehicle can be specified. The fifth tab allows to enable or disable certain advanced driver assistant systems to be considered in the vehicle. The last tab is dedicated to PTOs, either as a basic component or to simulate municipal vehicles such as refuse trucks or road sweepers with dedicated PTO activation either during driving or during standstill.

Relative File Paths

It is recommended to use relative filepaths. This way the Job File and all input files can be moved without having to update the paths. Example: “Demo\RT1.vrlm” points to the “Demo” subdirectory of the Vehicle File’s directoy.

VECTO automatically uses relative paths if the input file (e.g. Retarder Losses File) is in the same directory as the Vehicle File. (Note: The Vehicle File must be saved before browsing for input files.)

General vehicle parameters

Vehicle Category
Needed for Declaration Mode to identify the HDV Group.
Axle Configuration
Needed for Declaration Mode to identify the HDV Group.
Technically Permissible Maximum Laden Mass [t] (TPMLM)
Needed for Declaration Mode to identify the HDV Group.
HDV Group
Displays the automatically selected HDV Group depending on the settings above.

Masses/Loading

Corrected Actual Curb Mass Vehicle
Specifies the vehicle’s mass without loading
Curb Mass Extra Trailer/Body
Specifies additional mass due to superstructures on the vehicle or an additional trailer
Loading
Speciefies the loading of both, the vehicle and if available the trailer

Max. Loading displays a hint for the maximum possible loading for the selected vehicle depending on curb mass and TPMLM values (without taking into account the loading capacity of an additional trailer).

Note: VECTO uses the sum of Corrected Actual Curb Mass Vehicle, Curb Mass Extra Trailer/Body and Loading for calculation! The total mass is distributed to all defined axles according to the relative axle load share.

In Declaration Mode only the vehicle itself needs to be specified. Depending on the vehicle category and mission the simulation adds a standard trailer for certain missions.

Air Resistance and Corss Wind Correction Options

The product of Drag Coefficient [-] and Cross Sectional Area [m²] (cd x A) and Air Density [kg/m³] (see Settings) together with the vehicle speed defines the Air Resistance. Vecto uses the combined value c~d x A as input. Note that the Air Drag depends on the chosen Cross Wind Correction.

If the vehicle has attached a trailer for simulating certain missions the given cd x A value is increased by a fixed amount depending on the trailer used for the given vehicle category.

For cross wind correction four different options are available (see Cross Wind Correction for details):
  • No Correction: The specified CdxA value is used to compute the air drag, no cross-wind correction is applied
  • Speed dependent (User-defined): The specified CdxA value is corrected depending on the vehicle’s speed.
  • Speed dependent (Declaration Mode): A uniformly distributed cross-wind is assumed and used for correcting the air-drag depending on the vehicle’s speed
  • Vair & Beta Input: Correction mode if the actual wind speed and wind angle relative to the vehicle have been measured.

In delcaration mode the ‘Speed dependent (Declaration Mode)’ cross-wind correction is used.

Depending on the chosen mode either a Speed Dependent Cross Wind Correction Input File (.vcdv) or a Vair & Beta Cross Wind Correction Input File (.vcdb) must be defined. For details see Cross Wind Correction.

Dynamic Tyre Radius

In Engineering Mode this defines the effective (dynamic) wheel radius (in [mm]) used to calculate engine speed. In Declaration Mode the radius calculated automatically using tyres of the powered axle.

Axles/Wheels

For each axle the parameters Relative axle load, RRCISO and FzISO have to be given in order to calculate the total Rolling Resistance Coefficient.

In Engineering mode, the Wheels Inertia [kgm²] has to be set per wheel for each axle. The axles, for both truck and trailer, have to be given.

Use the and buttons to add or remove axles form the vehicle.

In Declaration mode only the axles of the truck have to be given (e.g., 2 axles for a 4x2 truck). The dynamic tyre radius is derived from the second axle as it is assumed this is the driven axle. For missions with a trailer, predefined wheels and load-shares are added by Vecto automatically.

Doubleclick entries to edit existing axle configurations.

Controls

New file
Create a new empty .vveh file
Open existing file
Open an existing .vveh file

Save current file

Save file as…

Send current file to the VECTO Editor
Note: If the current file was opened via the VECTO Editor the file will be sent automatically when saved.
Save and close file
If necessary the file path in the VECTO Editor will be updated.

Cancel without saving

Vehicle Editor – Powertrain Tab

Vehicle Idling Speed

The idling speed of the combustion engine can be increased in the vehicle settings. This may be necessary due to certain auxiliaries or for other technical reasons. This value is only considered if it is higher than the idling speed defined in the combustion engine.

Retarder Losses

If a separate retarder is used in the vehicle a Retarder Torque Loss Map can be defined here to consider idling losses caused by the retarder.

Four options are available:
  • No retarder
  • Included in Transmission Loss Maps: Use this if the Transmission Loss Maps already include retarder losses.
  • Primary Retarder (before gearbox): The rpm ratio is relative to the engine speed
  • Secondary Retarder (after gearbox): The rpm ratio is relative to the cardan shaft speed

Both, primary and secondary retarders, require an Retarder Torque Loss Input File (.vrlm).

The Retarder Ratio defines the ratio between the engine speed/cardan shaft speed and the retarder.

Angledrive

If an angledrive is used in the vehicle, it can be defined here. Three options are available:

  • None (default)
  • Separate Angledrive: Use this if the angledrive is measured separately. In this case the ratio must be set and the Transmission Loss Map (or an Efficiency value in Engineering mode) must also be given.
  • Included in transmission: Use this if the gearbox already includes the transmission losses for the angledrive in the respective transmission loss maps.

Vehicle Editor – Electric Components Tab

For hybrid vehicles and battery electric vehicles the input elements on the electric components tab are enabled. Here the component file for the eletric motor and battery pack can be loaded or created (see Electric Motor Editor, Electric Energy Storage Editor)

The position where the electric machine is positioned in the powertrain can be selected. It is possible that the electric machine is connected to the powertrain via a fixed gear ratio. At the moment electric machines are supported to be present at a single position only. It is not possible to have an electric motor at position P2 and another at position P4! However, it is possible that more than one electric machine is used at a certain position.

The Loss map EM ADC can be used to consider the losses of a transmission step between drivetrain and electric machine or to consider losses of a summation gear. The loss map has the same format as for all other transmission components (see Transmission Loss Map (.vtlm)). For simplicity or if no such transmission step is used it is possible to enter the efficiency directly (i.e., “1” if no transmission step is used).

In case of a P2.5 configuration (the electric motor is connected to an internal shaft of the tranmission) the transmission ratio for every single gear of the transmission has to be specified in the list to the right of the electric motor parameters. The ratio is defeined as \(n_\textrm{GBX,in} / n_\textrm{EM}\) in case of EM without additional ADC or \(n_\textrm{GBX,in} / n_\textrm{ADC,out}\) in case of EM with additional ADC.

For the electric energy storage multiple battery packs can be configured either in series or in parallel and the initial state of charge of the whole battery system can be defined. For every entry of a battery pack the number of packs (count) in series and a stream identifier need to be specified. Battery packs on the same stream are connected in series (e.g., two different battery packs on stream number 1 are in series) while all streams are then connected in parallel (see Battery Model for details). This is only supported for batteries and not for SuperCaps.

Double-click an entry to edit.

Click selected item.
addcycle Add REESS (.vbat)
remcycle Remove the selected REESS from the list

In the REESS Dialog the battery file itself and how it is connected to the electric system (i.e, the stream identifier and number of packs used) can be modified.

Vehicle Editor – Torque Limits Tab

On this tab different torque limits can be applied at the vehicle level. For details which limits are applicable and who the limits are applied in the simulation see here.

First, the maximum torque of the ICE may be limited for certain gears (see Engine Torque Limitations). In case that the gearbox’ maximum torque is lower than the engine’s maximum torque or to model certain features like Top-Torque (where in the highest gear more torque is available) it is possible to limit the engine’s maximum torque depending on the engaged gear.

Next, the maximum available torque for the electric machine can be reduced at the vehicle level, both for propulsion and recuperation. The input file is the same as the maximum drive and maximum recuperation curve (see Electric Motor Max Torque File)

Last, the overall propulsion of the vehicle (i.e., HEV Px, electric motor plus combustion engine) can be limited. The “Propulsion Torque Limit” curve limits the maximum effective torque at the gearbox input shaft over the input speed. This curve is added to the combustion engine’s maximum torque curve (only positive values are allowed!). For details on the file format see Vehicle Boosting Limits. The propulsion torque limit has to be provided from 0 rpm to the maximum speed of the combustion engine. In case of P3 or P4 configuration, the torque at the gearbox input shaft is calculated assuming that the electric motor does not contribute to propelling the vehicle, considering the increased losses in the transmission components inbetween. For P2.5 powertrain configurations no special calculations are necessary as this architecture is internally anyhow modelled as P2 architecture.

Vehicle Editor – ADAS Tab

On the ADAS tab, the advanced driver assistant systems present in the vehicle can be selected. See ADAS - Engine Stop/Start, ADAS - EcoRoll, and ADAS - Predictive Cruise Control

The following table describes which ADAS technology can be used and is supported for different powertrain architectures (X: supported, O: optional, -: not supported):

ADAS Technology  Powertrain Architecture Conventional HEV PEV
Engine Stop/Start X X -
EcoRoll Without Engine Stop X - -
EcoRoll with Engine Stop X - -
Predictive Cruise Control X X X
APT Gearbox EcoRoll Release Lockup Clutch O - -

Vehicle Editor – PTO Tab

PTO Transmission

If the vehicle has an PTO consumer, a pto transmission and consumer can be defined here. (Only in Engineering Mode)

Three settings can be set:

  • PTO Transmission: Here a transmission type can be chosen (adds constant load at all times).
  • PTO Consumer Loss Map (.vptol): Here the PTO Idle Loss Map of the pto consumer can be defined (adds power demand when the pto cycle is not active).
  • PTO Cycle (.vptoc): Defines the PTO Cycle which is used when the pto-cycle is activated (when the PTO-Flag in the driving cycle is set).

In engineering mode additional PTO activations are available to simulate different types of municipal vehicles. It is possible to add a certain PTO load during driving while the engine speed and gear is fixed (to simulate for example roadsweepers), or to add PTO activation while driving (to simulate side loader refuse trucks for example). In both cases the PTO activation is indicated in the driving cycle (column “PTO”).

Roadsweeper operation

PTO activation mode 2 simulates PTO activation while driving at a fixed engine speed and gear. The minimum engine speed and working gear is entered in the PTO tab. For details see PTO.

Sideloader operation

PTO activation mode 3 simulates a time-based PTO activation while driving. Therefore, a separate PTO cycle (.vptor) containing the PTO power over time has to be provided. The start of PTO activation is indicated with a ‘3’ in the ‘PTO’ column of the driving cycle. For details see PTO.

Engine Editor

Description

The Engine File (.veng) defines all engine-related parameters and input files like Fuel Consumption Map and Full Load Curve.

Relative File Paths

It is recommended to use relative filepaths. This way the Job File and all input files can be moved without having to update the paths. Example: “Demo\FLD1.vfld” points to the “Demo” subdirectory of the Engine File’s directory.

VECTO automatically uses relative paths if the input file (e.g. FC Map) is in the same directory as the Engine File. Note: The Engine File must be saved before browsing for input files.)

Main Engine Parameters

Make and Model [text]\
Free text defining the engine model, type, etc.
Idling Engine Speed [rpm]
Low idle, applied in simulation for vehicle standstill in neutral gear position.
Displacement [ccm]
Used in Declaration Mode to calculate inertia.
Inertia including Flywheel [kgm²]
Inertia for rotating parts including engine flywheel. In Declaration Mode the inertia is calculated depending on the engine’s displacement and also accounts for the clutch’s inertia.
Rated Speed [rpm]
This value represents the characteristic rated speed of the engine. It is not used in the simulation as the rated speed is derived from the full-load curve
Rated Power [rpm]
This value represents the characteristic rated power of the engine. It is not used in the simulation as the rated power is derived from the full-load curve
Max Torque [rpm]
This value represents the characteristic maximum torque of the engine. It is not used in the simulation as the maximum torque is derived from the full-load curve
Dual Fuel
If enabled, a secondary fuel can be specified.

Primary/Secondary Fuel

Fuel Type
Used to compute derived results such as fuel consumption in liters and CO2 values. This parameter influences the CO2-to-fuel ratio and fuel density. The actual values can be looked up in FuelTypes.csv.
Full Load and Drag Curves
The Engine’s Full Load and Drag Curves (.vfld) limits the engine’s maximum torque and drag torque respectively The full-load curve must at least cover the engine-speed range from idling speed up to the speed where the power goes down to 70% of the maximum power. The input file (.vfld) file format is described here.
Fuel Consumption Map
The Fuel Consumption Map is used to calculate the base FC value. See Fuel Consumption Calculation for details. The input file (.vmap) file format is described here.
WHTC Correction Factors

The WHTC Correction Factors are required in Declaration Mode for the WHTC FC Correction.

The Cold/Hot Emission Balancing Factor is an additional correction factor that is used to correct the fuel consumption.

In engineering a single correction factor for correcting WHTC, Cold/Hot Balancing, … can be specified.

Dual Fuel Engines

If the engine is operated in dual-fuel mode, enabling the checkbox “Dual Fuel Engine” shows an additional tab for providing the fuel type, fuel consumption map, and fuelconsumption correction factors for the second fuel. For dual-fuel engines the result files (.vmod, .vsum, XML reports) contain the fuel consumption for each fuel separately and the total CO2 emissions.

Waste Heat Recovery

In case the engine is equipped with a waste heat recovery system (WHR) the WHR type can be selected in the lower right part of the window. For WHR systems that generate mechanical power that is directly delivered to the engine’s crankshaft no further input is required - the WHR shall be considered in the fuel consumption map already.

For WHR systems with electrical power output the generated electrical power needs to be provided in the Fuel Consumption Map of the primary fuel.

For WHR systems with mechanical power output to the drivetrain the generated mechanical power needs to be provided in the Fuel Consumption Map of the primary fuel.

The final fuel consumption is at the end corrected for the electric and mechanical energy generated by the WHR system (see fuel consumption correction) Similar correction factors as applied for the fuel consumption (WHR Correction factors) have to be provided for the WHR system. The weighting of these correction factors is the same as for the WHTC correction factors.

Chart Area

The Chart Area shows the fuel consumption map and the selected full load curve. The fuel consumption map of the primary fuel is plotted in red and if provided the secondary fuel is plotted in green.

Controls

newNew file
Create a new empty .veng file
openOpen existing file
Open an existing .veng file

saveSave current file

SaveAsSave file as…

sendtoSend current file to the VECTO Editor
Note: If the current file was opened via the VECTO Editor the file will be sent automatically when saved.

Open file browser.

Open file (see File Open Command).

OKSave and close file
If necessary the file path in the VECTO Editor will be updated.

CancelCancel without saving

Gearbox Editor

Description

The Gearbox File (.vgbx) defines all gearbox-related input parameters like gear ratios and transmission loss maps. Furthermore, certain parameters for the gearshift strategy such as the gearshift lines can be provided (see Gear Shift Model for details).

Relative File Paths

It is recommended to use relative filepaths. This way the Job File and all input files can be moved without having to update the paths.
Example: “Gears\Gear1.vtlm” points to the “Gears” subdirectory of the Gearbox File’s directoy.

VECTO automatically uses relative paths if the input file (e.g. Shift Polygons File) is in the same directory as the Gearbox File. (The Gearbox File must be saved before browsing for input files.)

Main Gearbox Parameters

Make and Model
Free text defining the gearbox model, type, etc.
Transmission Type
Depending on the transmission type some options below are not available. The following types are available:
  • MT: Manual Transmission
  • AMT: Automated Manual Transmission
  • APT-S: Automatic Transmission with torque converter - Serial configuration
  • APT-P: Automatic Transmission with torque converter - Power Split configuration
  • APT-N: Automatic Transmission without torque converter, only applicable for pure electric vehicles

For more details on the automatic transmission please see the APT-Model

Inertia [kgm²]
Rotational inertia of the gearbox (constant for all gears). (Engineering mode only)
Traction Interruption [s]
Interruption during gear shift event. (Engineering mode only)

Gears

Use the add and remove buttons to add or remove gears from the vehicle. Doubleclick entries to edit existing gears.

  • Gear “Axle” defines the ratio of the axle transmission / differential.
  • “Ratio” defines the ratio between the input speed and output speed for the current gear. Must be greater than 0.
  • “Loss Map or Efficiency” allows to define either a constant efficiency value or a loss map (.vtlm). Note: efficiency values are only allowed in engineering mode
  • “Shift polygons” defines the Shift Polygons InputFile (.vgbs) for each gear. Not allowed in Declaration Mode. See GearShift Model for details.
  • “Max Torque” defines the maximum allowed torque (if applicable) for a gear. It is used for limiting the engine’s torque in certain gears. Note: in Declaration mode the generic shift polygons are computed from the engine’s full-load curve. If the maximum torque is limited by the gearbox, the minimum of the gearbox and engine maximum torque will be used to compute the generic shift polygons!

Gear shift strategy parameters

Some parameters influencing the gearshift behavior can be defined in the gearbox file. Therefore, the gearbox file has to be provided as input for the shift strategy parameters as well. See Gearbox-TCU for more details.

In addition, the gearshift polygon affects the gearshift behavior to a certain degree. The gearshift polygon can be defined individually for each gear. If no shift polygon is provided the declaration mode shift polygons for the selected transmission type are used.

The gearshift strategy depends on the transmission type:

Manual Transmission
Shiftline based approach. The calculation of gearshift lines and the gearshift rules are described here
Automated Manual Transmission - Conventional vehicle
Efficiency shift. The calculation of gearshift lines and the gearshift rules are described here
Automated Manual Transmission - Hybrid Electric vehicle
Gearshift is handled by the hybrid controller. Shift lines (calculated in the same way as for conventional vehicles) are used as upper and lower boundary for allowed ICE operating points.
Automated Manual Transmission - Pure Electric vehicle
Efficiency shift based strategy. The calculation of gearshift lines and the gearshift rules are described here
Automatic Transmission - Conventional vehicle
Efficiency shift. The calculation of gearshift lines and the gearshift rules are described here
Automatic Transmission - Hybrid Electric vehicle
Gearshift is handled by the hybrid controller. Shift lines (calculated in the same way as for conventional vehicles) are used as upper and lower boundary for allowed ICE operating points.
Automatic Transmission (APT-N) - Pure Electric vehicle
Efficiency shift based strategy. The calculation of gearshift lines and the gearshift rules are described here

Gearshift Parameters

Torque reserve
The minimal torque reserve which has to be provided after a gearshift. Only used for MT transmissions.
Minimum time between gearshifts
Defines the time interval between two consecutive gearshifts. Has to be greater than 0. This time interval is ignored if the engine speed gets too high or too low.

Shift Strategy Parameters

The user interface contains input fields for the following parameters:
  • Downshift after upshift delay: to prevent frequent (oscilating) up-/down shifts this parameter blocks downshifts for a certain period after an upshift
  • Upshift after downshift delay: to prevent frequent (oscilating) up-/down shifts this parameter blocks upshifts for a certain period after a downshift
  • Min acceleration after upshift: after an upshift the vehicle must be able to accelerate with at least the given acceleration. The achievable acceleration after an upshift is estimated on the current driving condition and powertrain state.

Start Gear

In order to calculate an appropriate gear for vehicle start (first gear after vehicle standstill) a fictional load case is calculated using a specified reference vehicle speed and reference acceleration together with the actual road gradient, transmission losses and auxiliary power demand. This way the start gear is independent from the target speed. VECTO uses the highest possible gear which provides the defined torque reserve.

Reference vehicle speed at clutch-in
The reference vehicle speed
Reference acceleration at clutch-in
The reference acceleration

Torque Converter

Torque converter characteristics file
Defines the Torque converter characteristics file containing the torque ratio and reference torque over the speed ratio.
Inertia [kgm²]
Rotational inertia of the engine-side part of the torque converter. (Gearbox-side inertia is not considered in VECTO.)
Reference RPM
Defines the reference speed at which the torque converter characteristics file was measured.
Max. Speed
Defines the maximum input speed the torque converter can handle.
Torque converter shift polygon
Defines the Shift Polygons InputFile (.vgbs) separately for the torque converter. For details on shifting from/to the torque converter gear please see AT Gear Shift Strategy.

Torque Converter: Minimal acceleration after upshift

Here the minimal achievable accelerations before upshifts can be defined.

Acc. for C->L [m/s²]
The minimal achievable acceleration for shifts from torque converter gear to locked gear.
Acc. for C->C [m/s²]
The minimal achievable acceleration for shifts from first torque converter gear to second torque converter gear (1C->2C)

Power shift losses

Shift time [s]
The shift time for powershift losses.

Chart Area

The Chart Area displays the Shift Polygons Input File(.vgbs) as well as the declaration mode shift polygons (dashed lines) for the selected gear together with the engine’s full-load curve.

Controls

New file
Create a new empty .vgbx file
openOpen existing file
Open an existing .vgbx file

save Save current file

SaveAs Save file as…

sendto Send current file to the VECTO Editor
Note: If the current file was opened via the VECTO Editor the file will be sent automatically when saved.

Open file browser

Open file (see File Open Command).

OK Save and close file
If necessary the file path in the VECTO Editor will be updated.

Cancel Cancel without saving

Hybrid Strategy Parameters Editor

Description

The Hybrid Strategy Parameters File (.vhctl) defines all parameters used by the Hybrid Control Strategy to evaluate the best option for splitting the demanded torque between electric motor and combustion engine.

Strategy Parameters

The hybrid control strategy evaluates different allocations of torque to the electric motor and different gears and calculates the following cost function:

\(C = \sum_{i \in \textrm{Fuels}}{FC_{i} \cdot NCV_{i} \cdot dt} + f_{\textrm{equiv}} \cdot (P_\textrm{Bat} \cdot dt + C_{\textrm{Pen1}}) \cdot f_{SoC} + C_{\textrm{Pen2}}\)

\(f_\textrm{SoC} = 1 - \left(\frac{\textrm{SoC} - \textrm{TargetSoC}}{0.5 \cdot (\textrm{SoC}_\textrm{max} - \textrm{SoC}_{min}} \right)^e + C_\textrm{SoC}\)

The parameters for the cost function can be defined in the hybrid strategy file.

Evquivalence Factor Discharge
\(f_{\textrm{equiv}}\) in case the battery is discharged
Evquivalence Factor Charge
\(f_{\textrm{equiv}}\) in case the battery is charged
Min SoC
\(\textrm{SoC}_\textrm{min}\)
Max SoC
\(\textrm{SoC}_\textrm{max}\)
Target SoC
\(\textrm{TargetSoC}\)
Min ICE On Time
In case the ICE was turned on, it cannot be turned of for this period of time
Aux Buffer Time
In case electric auxiliaries are connected to the high-voltage system, reserve a certain amount of energy in the battery to supply the auxiliaries for this period of time.
Aux Buffer Charge Time
In case electric auxiliaries are connected to the high-voltage system and the reserved energy for the auxiliaries is used, re-charge the “auxiliaries buffer” in within this period of time.
ICE Start penalty factor
Penalty added to the cost function in case the ICE needs to be turned on
Cost Factor SoC Exponent
Exponent \(e\) in the cost function

Electric Motor Editor

Description

The electric motor file defines all parameters relevant for the electric machine. These are the motor’s maximum drive and recuperation torque, the drag torque as well as the electric power map.

Relative File Paths

It is recommended to use relative filepaths. This way the Job File and all input files can be moved without having to update the paths.

VECTO automatically uses relative paths if the input file (e.g. elctric power map) is in the same directory as the Electric Motor File. (The Electric Motor File must be saved before browsing for input files.)

Main Parameters

Make and Model
Free text defining the gearbox model, type, etc.
Inertia [kgm²]
Rotational inertia of the gearbox (constant for all gears). (Engineering mode only)
Continuous Torque [Nm]
The nominal torque the electric machine can provide continuously
Test Speed Continous Torque [rpm]
Angular speed at which the continouos torque can be provided
Overload Torque [Nm]
Maximum torque above the continuous torque the electric motor can provide for a certain time
Test Speed Overload Torque [rpm]
Angular speed at which the overload torque was measured
Overload Duration [s]
The time interval the electric machine can operate at its peak performance
Thermal Overload Recovery Factor
The accumulated overload energy has to be below the max. overload capacity multiplied by this factor so that the peak power is available again.
Drag Torque Curve
The motor’s drag torque over engine speed when the motor is not energized. The torque values in the drag curve have to be negative. (see Electric Motor Drag Curve File (.vemd))
Max. Drive and Max. Generation Torque Curve
Torque over engine speed the electric motor can apply on its output shaft. (see Electric Motor Max Torque File (.vemp)). The max drive and max generation torque have to be provided for two different voltage levels.
Electric Power Consumption Map
Defines the electric power that is required to provide a certain mechanical power (torque and angular speed) at the motor’s shaft. This map is used to calculate the electric power demand. The electric power consumption map shall cover a torque range exceeding the max. drive and max. generation torque and shall cover the speed range from 0 up to the maximum speed. (see Electric Motor Map (.vemo)). The power map has to be provided for two different voltage levels.
Voltage Level Low/High
Applicable voltage level for the electric power consumption map and max drive/generation torque curve

Chart Area

The Chart Area displays the electric machine’s max. drive curve and max. generation curve (blue), the drag curve (green) and the entries provided in the electric power consumption map (red).

Controls

New file
Create a new empty .vem file
openOpen existing file
Open an existing .vem file

save Save current file

SaveAs Save file as…

sendto Send current file to the VECTO Editor
Note: If the current file was opened via the VECTO Editor the file will be sent automatically when saved.

Open file browser

Open file (see File Open Command).

OK Save and close file
If necessary the file path in the VECTO Editor will be updated.

Cancel Cancel without saving

Rechargeable Electric Energy Storage Editor

Two types of rechargeable electric energy storage can be configured in VECTO: either a battery pack or a super capacitor.

Battery Pack

Description

The electric energy storage editor allows to edit all model parameters relevant for the electric energy storage.

Relative File Paths

It is recommended to use relative filepaths. This way the Job File and all input files can be moved without having to update the paths.

VECTO automatically uses relative paths if the input file (e.g. SoC) is in the same directory as the Battery file. (The Battery File must be saved before browsing for input files.)

Main Parameters

Make and Model
Free text defining the model, type, etc.
Capacity [Ah]
Nominal capacity of the battery
C-Factor [-]
Factor defining the battery’s maximum current (derived from the capacity)
SoC min [%]
Minimum allowed state of charge
SoC max [%]
Maximum allowed state of charge
SoC Curve
Battery internal voltage depending on the battery’s state of charge (see Battery Internal Voltage File (.vbatv))
Internal Resistance Curve
Defines the battery’s internal resistance depending on its state of charge. The file must cover the SOC range from 0 to 100%! (see Battery Internal Resistance File (.vbatr))

Chart Area

The Chart Area displays the battery’s internal voltage (blue) and the internal resistance (red) over its state of charge.

SuperCap

Main Parameters

Make and Model
Free text defining the model, type, etc.
Capacitance [F]
Nominal capacity of the capacitor
Min Voltage [V]
Minimum allowed state of charge
Max Voltage [v]
Maximum allowed state of charge
Internal Resistance
Defines the capacitor’s internal resistance

Controls

New file
Create a new empty .vbat file
openOpen existing file
Open an existing .vbat file

save Save current file

SaveAs Save file as…

sendto Send current file to the VECTO Editor
Note: If the current file was opened via the VECTO Editor the file will be sent automatically when saved.

Open file browser

Open file (see File Open Command).

OK Save and close file
If necessary the file path in the VECTO Editor will be updated.

Cancel Cancel without saving

Graph Window

Description

The Graph Window allows to visualise modal results files (.vmod). Multiple windows can be open at the same time to display different files.

Note that the graph does not update automatically if the results file has changed.

Channels

Use the add and remove buttons to add or remove channels. Doubleclick entries to edit existing channels.

Each channel can be plotted either on the left or on the right Y Axis. Use the checkbox to disable channels in the graph.

X Axis Controls

The X Axis can either show distance or time.

Min, Max
Sets the range for the x axis.
Reset button
Reset the x axis range to display the complete cycle.
+, - buttons
Zoom in/out on the x axis.
<, > buttons
Move the x axis range left/right.

Controls

open Open a .vmod file

Open a new Graph Window

Reload the currently open file

Command Line Arguments

The Vecto 3.x commandline tool can be used to start simulations from the command line and runs without graphical user interface. If multiple job-files are specified or a job-file contains multiple simulation runs (i.e., multiple cycles and/or loadings) these simulations are executed in parallel.

General Notes

  • The order in which the arguments are provided is arbitrary.
  • If a file path includes space characters (e.g. “C:\VECTO Test Files\Demo.vecto”) then double quotes have to be used (as in the picture above).
  • If not the complete file path is defined (e.g. “file1.vecto” instead of “c:\data\file1.vecto”) then VECTO expects the file in the application directory (where vectocmd.exe is located).

Basic usage

    vectocmd.exe [-h] [-v] FILE1.(vecto|xml) [FILE2.(vecto|xml) ...]

List of command line arguments

  • FILE1.vecto [FILE2.vecto …]: A list of vecto-job files (with the extension: .vecto). At least one file must be given. Delimited by whitespace.
  • -t: output information about execution times
  • -mod: write mod-data in addition to sum-data
  • -eng: switch to engineering mode (implies -mod)
  • -v: Shows verbose information (errors and warnings will be displayed)
  • -vv: Shows more verbose information (infos will be displayed)
  • -vvv: Shows debug messages (slow!)
  • -vvvv: Shows all verbose information (everything, slow!)
  • -V: show version information
  • -h: Displays this help.

Calculation Modes

VECTO supports different calculation modes for declaring a vehicle, validation of test-results, or experimenting with different parameters and components. These modes are described here.

In the GUI the Calculation Mode can be changed via the Options Tab of the Main Form.

In the Command Line the default Calculation Mode is Declaration, but can be changed to Engineering with the “-eng” flag.

Engineering Mode

The Engineering Mode lets the user define every aspect in the component models of the vehicle and the driving cycle. This is for experimenting and validation purposes.

In this mode the given list of job files is simulated with the respective driving cycles. Each job file defines a separate vehicle.

Requirements

  • One or more checked job files in the Job List
  • Each job file must include at least one driving cycle

Results

  • Modal results (.vmod). One file for each vehicle/cycle combination. Modal results are only written if the modal output is enabled in the ‘Options’ tab on the Main Window
  • Sum results (.vsum). One file for each invocation of VECTO.

Options

The Driving Cycle determines the simulation method in engineering mode. The option depends directly on the driving cycle input and cannot be set explicitely. For more information about the formats see Driving Cycles.

Note: Time-based driving cycles support arbitrary time steps. However, certain actions are simulated within a single simulation interval (e.g. closing the clutch after a gear switch) and may thus result in artefacts during the simulation due to engine inertia, gearbox inertia, etc. Thus the suggested minimum time interval for time-based cycles is 0.5s!

Declaration Mode

In Declaration Mode many input parameters are predefined for the official certification. They are locked in the user interface and will automatically be set by VECTO during calculation. Calculations will be performed for each mission profile (of the corresponding HDV class) with two different loadings: low loading and reference loading. 

Declaration Mode can be activated in the Options Tab.

Requirements

  • One or more checked job files in the Job List
  • The job files don’t need to include driving cycles. These are automatically assigned.

Results

  • Modal results (.vmod). One file for each vehicle/cycle/loading combination. Modal results are only written if the modal output is enabled in the ‘Options’ tab on the Main Window
  • Sum results (.vsum). One file for each invocation of VECTO.
  • Results (.xml). One file for each job.

Verification Test Mode

The purpose of the verification test is to simulate a vehicle defined in declaration mode on a measured real-driving cycle. This simulation mode uses its own cycle format, requiring mainly vehicle speed, wheel speed, wheel torque, engine-fan speed, and engine speed. VECTO then calculates the appropriate gear and simulates the cycle. Auxiliary power is according to the technologies defined in the vehicle. However, the engine fan auxiliary is ignored and the power demand for the engine fan is calcuated based on the engine-fan speed. The power demand for the other auxiliaries depends on the vehicle’s actual speed. The fuel consumption is calculated using the engine speed from the driving cycle and the torque demand as given in the cycle, adding the losses of all powertrain components.

Requirements

  • One or more checked job files in the Job List
  • Each job must include a vehicle in declaration mode (XML)
  • Each job file must include at least one driving cycle

Results

  • Modal results (.vmod). One file for each vehicle/cycle combination. Modal results are only written if the modal output is enabled in the ‘Options’ tab on the Main Window
  • Sum results (.vsum). One file for each invocation of VECTO.

Requirements

  • One or more checked job files in the Job List
  • Each job must include a vehicle in declaration mode (XML)
  • Each job must include the manufacturer report (XML) of the vehicle as generated for the vehicle declaration
  • Each job file must include exactly one driving cycle (in case multiple driving cycles are provided, only the first cycle is simulated!)

Results

  • VTP Report (.xml). Contains a description of the vehicle and its components, the verification test analysis according to the draft legislation, and a validation of the input data digest values
  • Modal results (.vmod). One file for each vehicle/cycle combination. Modal results are only written if the modal output is enabled in the ‘Options’ tab on the Main Window
  • Sum results (.vsum). One file for each invocation of VECTO.

Validations

  • Before the simulation of the measured VTP cycle starts, the provided cycle data is passed through some sanity checks:
  • The cycle is provided in 2Hz
  • The ratio of wheel speeds (left/right) should be lower than 1.4 for wheel speeds above 0.1rpm
  • The absolute difference of wheel speeds (left/right) should be lower than 1rpm for wheel speeds below 0.1rpm
  • The torque ratio (left/right) should be lower than 3 and the absolute difference should be lower than 200Nm.
  • The fan speed shall be between 20 and 4000rpm, unless the vehicle is equipped with an electric fan
  • The fuel consumption within a window off 10min should be between 180 and 600 g/kWh_(PWheel_pos)

In case the provided cycle exceeds these limits an according warning message is shown in the user interface and written to the report.

Engine-Only Mode

When this mode is enabled in the Job File then VECTO only calculates the fuel consumption based on a load cycle (engine speed and torque). In the Job File only the following parameters are needed:

The driving cycle also has to be in a special format which is described here: Engine Only Driving Cycle.

Simulation Models

In this chapter the used component models for the simulation are described.

Supported Powertrain Architectures

The following xEV architectures are currently supported in VECTO. All architectures can be used together with the bus auxiliaries model in engineering mode.

Parallel Hybrid Electric Vehicle Architectures

  • P1 + AMT
  • P1 + APT-S/P
  • P2 + AMT
  • P2.5 + AMT
  • P2.5 + APT-S/P
  • P3 + AMT
  • P3 + APT-S/P
  • P4 + AMT
  • P4 + APT-S/P

Pure Electric Vehicle Architectures

  • E2 + AMT
  • E2 + APT-N
  • E3
  • E4

Powertrain and Components Structure

The powertrain in Vecto V3 consists of the following components which are generally connected in this order:

The engine tries to supply the requested power demand (including all power losses happening in the powertrain and auxiliaries). If the engine can’t supply the given power demand, the driver reduces the accelerating.

Powertrain Values

The powertrain can be configured to represent different situations depending on the used retarder and gearbox configuration. The output values in the Modfile depict different points in the powertrain depending on the current configuration. Here are some schematic overviews which show the values and the position in the powertrain they represent:

AMT Transmission Input Retarder

AMT Transmission Output Retarder

AT Transmission Input Retarder

AT Transmission Output Retarder

Axle

Driver: Acceleration Limiting

VECTO limits the vehicle acceleration and deceleration depending on current vehicle speed, to model a realistic driver behavior. These limits are defined in the Acceleration Limiting Input File (.vacc), which can be set in the Job File. In Declaration mode this is already predefined.

The graph shows the acceleration and deceleration limits depending on the current vehicle speed.

Driver: Look-Ahead Coasting

Look-Ahead Coasting is a function that aims on modelling real driver behaviour. It is a forward-looking function that detects forthcoming reductions in target speed in the mission profile (e.g. speed limit, etc.) and induces an early deceleration using engine braking before applying mechanical brakes according to the deceleration limit.

At the resulting deceleration start point the model calculates the coasting trajectory until it meets the brake deceleration trajectory. The resulting deceleration consists of a coasting phase followed by combined mechanical/engine braking. If Look-Ahead Coasting is disabled only the braking phase according to the deceleration limit will be applied.

Since Vecto 3.0.4 the coasting strategy according to the ACEA White Book 2016 is implemented.

The look ahead coasting functionality represents the driver behavior prior to a deceleration event. Due to information of the route ahead the driver is able to anticipate on the deceleration event by releasing the accelerator pedal.

This pedal release decision is based on an estimation of kinetical and potential (height) energy gain versus the expected dissipated energy tue to vehicle resistances during the route section ahead.

For an upcoming target speed change the energy level after the speed change is compared to the vehicle’s current energy level (kinetic and potential energy). The difference of those energy levels is used to estimate the average deceleration force to reach the next target speed. Coasting starts if the vehicle’s (estimated) average resistance force during coasting multiplied by a speed dependent ‘Decision Factor’ becomes smaller than the average deceleration force. (For details on the equations please see the ACEA White Book 2016, Section 8)

The Decision Factor (DF) depends on the next target speed and the speed change:

\(DF_{Coasting} = 2.5 - 1.5 * DF_{vel} * DF_{vdrop}\)

whereas \(DF_{vel}\) and \(DF_{vdrop}\) are speed dependent and speed change dependent lookup curves, giving a value from 0 and 1.

For the look ahead coasting target speed changes within the preview distance are considered.

\(preview distance [m] = 10 * vehicle speed [km/h]\)

Parameters in Job File:
  • PreviewDistanceFactor
  • DF_offset: offset in the equation for DFcoasting (default 2.5)
  • DF_scaling: factor in the equation for DFcoasting (default 1.5)
  • DF_targetSpeedLookup: csv file for DFvel lookup (see below)
  • Df_velocityDropLookup: csv file for DFvdrop lookup (see below)

In engineering mode the parameters can be freely chosen while in declaration mode the default values are used.

Decision Factor for target velocity lookup (DFvel)

Example (default values):

v_target [km/h], decision_factor [-]
0              , 0
48             , 0
52             , 1
100            , 1

Decision Factor for velocity drop lookup (DFvdrop)

Example (default values):

v_drop [km/h], decision_factor [-]
-100          , 1
9             , 1
11            , 0
100           , 0

Driver: Overspeed

Overspeed controls the vehicle’s behaviour on uneven road sections (slope ≠ 0) and can be configured in the Job File’s Driver Assist Tab. Overspeed is designed to model an average driver’s behaviour without the aid of driver assistance systems. Eco-Roll  represents an optional driver assistance feature. For this reason vehicles without Eco-Roll should always have the Overspeed function enabled.

Overspeed activates as soon as the total power demand at the wheels (Pwheel) falls below zero, i.e. the vehicle accelerates on a negative slope. The clutch remains closed, engine in motoring operation, and the vehicle accelerates beyond the cycle’s target speed. When the speed limit (target speed plus Max. Overspeed) is reached the mechanical brakes are engaged to prevent further acceleration.

Example with target (purple) and actual speed (orange) on the top left axis, slope (brown) on the top right axis. The bottom graph shows engine power (blue), motoring curve (orange) and mechanical brake power (green). In this example Overspeed is allowed until the vehicle’s speed exceeds target speed by 5 [km/h].

Parameters in Job File:
  • Minimum speed [km/h]. Below this speed the function is disabled.
  • Max. Overspeed [km/h] (relative to target speed)

Advanced Driver Assistant Systems: Engine Stop/Start

Description

If engine stop/start is enabled in the Vehicle, the engine is turned off during vehicle stops to reduce the fuel consumption. During vehicle stops the energy demand for certain auxiliaires and for starting the engine is accumulated. In a post-processing step the final fuel consumption is corrected to consider the energy demand for the auxiliaries and engine start.

Model Parameters

  • Delay engine-off: if the vehicle stops, the engine is switched off after this timespan
  • Max engine-off timespan: if the enine is switched off at a vehicle stand, the engine is turned on again after this timespan. This basically limits the max. time the engine is switched off at a single engine-off event.
  • Engine stop/start utility factor: In practice, the engine is not switched off at every vehicle stop. This is considered with this utility factor (0…1). Further details are provided below.
  • delay engine-off: 2 s
  • Max engine-off timespan: 120 s
  • Engine stop/start utility factor: 0.8

Engine Start-Up Energy Demand

The energy demand to ramp-up the engine depends on the engine’s inertia and the engine’s drag torque and is computed according to the following equation:

\(E_{ICE,rampUp} = 0.5 * I_{ICE} * n_{idle}^2 + T_{drag}(n_{idle}) * n_{idle} / 2 * t_{ICE,start}\)

\(E_{ICE,start} = E_{ICE,rampUp} / \eta_{alternator}^2\)

\(E_{ICE,start}\) is the amount of energy the combustion engine needs to provide to compensate the start up is the ramp-up energy multiplied by the efficiency of the alternator. \(t_{ICE,start}\) is assumed to be 1 second and \(\eta_{alternator}\) is 0.7.

Auxiliaries and Utility Factor

During ICE-off phases the ICE is fully shut of in the simulation (.vmod data). However, in reality the ICE is not always switched off due to certain boundary conditions (e.g. power demand from an auxiliary, temperature, etc.). This is considered in the post-processing. Therefore, the demand for different auxiliaries is balanced in separate columns in the .vmod file for the two cases a) ICE is really off, and b) ICE would be on. This is done for the mechanical auxiliaries, bus-aux electric demand (all different cases like ES connected to the REESS, smart ES, conventional ES, and combinations thereof), bus-aux pneumatic system. A detailed description which auxiliary power demand is balanced in which columns can be found in this spreadsheet for all combinations of conventional vehicles, bus auxiliaries, and hybrid vehicles.

Auxiliary energy demand

In Declaration Mode the energy demand of all auxiliaries except the engine cooling fan and the steering pump is considered during vehicle stops.

Auxiliary energy demand

In Engineering Mode the energy demand of the auxiliaries can be specified for the cases: - ICE on - ICE off, vehicle standstill - ICE off, vehicle driving

Advanced Driver Assistant Systems: Eco-Roll

Description

Eco-roll is a driver assistant system that automatically decouples the internal combustion engine from the power train during specific downhill driving conditions with low negative slopes. The aim is to save fuel during such phases. VECTO supports eco-roll without engine stop/start and eco-roll with engine stop/start. In the former case, the combustion engine is idling during eco-roll phases while in the latter case the combustion engine is turned off during eco-roll events. For vehicles having eco-roll with engine stop/start the fuel consumption is corrected for the engine stop/start events and the auxiliary power demand during engine-off phases.

In case of AT gearboxes eco-roll can either be performed by shifting to neutral, i.e., disengaging the gearbox, or opening the torque converter lockup clutch. Which option is supported by the transmission needs to be specified in the vehicle configuration.

Auxiliary energy demand

In Declaration Mode the energy demand of all auxiliaries is applied in the fuel consumption correction during engine-off periods

Auxiliary energy demand

In Engineering Mode the energy demand for the different states - ICE on - Vehicle driving, ICE off - Vehicle standstill, ICE off

can be specified. When the ICE is on, the auxiliary energy demand is directly applied. The auxiliary energy demand during ICE-off phases is corrected in post-processing.

Model Parameters

  • Minimum speed: minimum vehicle speed to allow eco-roll to be activated
  • Activation delay: delay between the point in time when all conditions for an eco-roll event are fulfilled until eco-roll is activated
  • Underspeed threshold: Threshold below the target speed to disable eco-roll
  • AT EcoRoll Release Lockup Clutch: Required only for AT transmissions. If set to true, the lockup clutch is released during eco-roll events and the gear is engaged. If set to false, the gearbox switches to neutral.
  • Minimum speed: 60 km/h
  • Activation delay: 2s
  • Underspeed threshold: 0 km/h

Eco-Roll Model

Calulations during simulation

\(a_{veh,est} = \frac{F_{grad}(x) + F_{roll}(x) + F_{aero}(v_{veh})}{m_{veh}}\)

Eco-Roll State Diagram

The following state diagram depicts when eco-roll is activated during the simulation.

Advanced Driver Assistant Systems: Predictive Cruise Control

Description

Predictive cruise control (PCC): systems which optimise the usage of potential energy during a driving cycle based on an available preview of road gradient data and the use of a GPS system. A PCC system declared in the input to the simulation tool shall have a gradient preview distance longer than 1000 meters and cover all following use cases:

Use Case 1: Crest Coasting

Approaching a crest the vehicle velocity is reduced before the point where the vehicle starts accelerating by gravity alone compared to the set speed of the cruise control so that the braking during the following downhill phase can be reduced.

Use Case 2: Accelerating without Engine Power

During downhill driving with a low vehicle velocity and a high negative slope the vehicle acceleration is performed without any engine power usage so that the downhill braking can be reduced.

Use Case 3: Dip Coasting

During downhill driving when the vehicle is braking at the overspeed velocity, PCC increases the overspeed for a short period of time to end the downhill event with a higher vehicle velocity. Overspeed is a higher vehicle speed than the set speed of the cruise control system.

In VECTO a vehicle may either support use cases 1 and 2 or all three use cases.

Predictive cruise control is only considered on highway sections of the simulated driving cycle (see sistance-based driving cycle.

In declaration mode, the whole long-haul cycle is considered as highway. Moreover, the section from 29760m to 96753m of the regional delivery cycle is considered as highway.

Model Parameters

  • Allowed underspeed: Threshold below the target speed the vehicle’s velocity may be reduced to during a PCC event (use-case 1 & 2, \(v_{neg}\))
  • Allowed overspeed: Threshold above the target speed the vehicle’s velocity may reach during a PCC event (use-cae 3)
  • PCC enabling velocity: Only highway sections of the driving cycle with a target velocity greater than or equal to the enabling velocity are considered for PCC events.
  • Minimum speed: Minimum vehicle speed for allowing PCC use-case 2
  • Preview distance use case 1: Preview distance for use-case 1 PCC events. After this distance (estimated) after starting the PCC event the vehicle shall reach the target speed again.
  • Preview distance use case 2: Preview distance for use-case 2 PCC events. After this distance (estimated) after starting the PCC event the vehicle shall reach the target speed again. This distance is typically shorter than the preview distance for use-case 1 as only the acceleration phase is considered.
  • Allowed underspeed: 8 km/h
  • Allowed overspeed: 5 km/h
  • PCC enabling velocity: 80 km/h
  • Minimum speed: 50 km/h
  • Preview distance use case 1: 1500 m
  • Preview distance use case 2: 1000 m

Predictive Cruise Control Model Use-cases 1 and 2

Pre-Processing

  1. In a preprocessing step the road gradient where the vehicle would accelerate on its own is computed for certain velocities. If the vehicle is equipped with eco-roll the powertrain is declutched, otherwise the engine is in full drag. The slope is calculated for every simulated cycle as this values vary with the vehicle’s payload, rolling resistance and air drag.
  2. All positions in the driving cycle where the slope is lower than the road gradient required that the vehicle accelerates on its own are marked as potential candidates for PCC events. At this distance the vehicle’s velocity shall be a minimum. Denoted as \(x_{v_{low}}\).
  3. For every potential PCC event, the end position is marked in the driving cycle. This is the first position in the driving cycle after \(x_{v_{low}}\) where the slope is greater than the road gradient required that the vehicle accelerates on its own. Latest at this position the vehicle shall reach the target velocity again. Denoted as \(x_{end, max}\)
  4. For every potential PCC event, the earliest start position is marked. This is calculated as \(x_{start} = x_{v_{low}} - d_{preview}\).
  5. For every potential PCC event, the vehicle’s energy is calculated: \(E(x_{v_{low}}) = m \cdot g \cdot h(x_{v{low}}) + \frac{m \cdot (v_{target}(x_{v_{low}}) - v_{neg})^2}{2}\) \(E(x_{end, max}) = m \cdot g \cdot h(x_{end, max}) + \frac{m \cdot v_{target}(x_{end, max})^2}{2}\)

Calulations during simulation

If the vehicle enters a potential PCC section, the following calculations are performed to decide on starting a PCC event:

  1. Current vehicle position: \(x\)
  2. Position in the cycle where the PCC event shall be finished: \(x_{end} = min(x + d_{preview}, x_{end, max})\)
  3. Estimation of coasting resistance force:
    \(F_{coast}(x) = \frac{P_{roll}(x) + P_{aero}(x, v_{target}) + P_{ice, drag} + P_{em, drag}}{v_{target}}\)
    \(P_{ice, drag}\) is set to 0 in case the vehicle is equipped with eco-roll and pure electric vehicles. \(P_{em,drag}\) is set to 0 for conventional vehicles.
  4. Energy demand/gain for coasting from the vehicle’s current position to the point with the minimum velocity \(x_{v_{low}}\):
    \(E_{coast, v_{low}} = F_{coast} \cdot (x_{v_{low}} - x)\)
  5. Energy demand/gain for coasting from the vehicle’s current position to the end of the PCC event \(x_{end}\):
    \(E_{coast, x_{end}} = F_{coast} \cdot (x_{end} - x)\)
  6. Vehicle’s current energy:
    \(E_{veh}(x) = m \cdot g \cdot h(x) + \frac{m \cdot v_{veh}^2}{2}\)
  7. Vehicle’s energy at the end of a PCC event:
    \(E(x_{end}) = m \cdot g \cdot h(x_{end}) + \frac{m \cdot v_{target}(x_{end})^2}{2}\)

PCC State Diagram

The following state diagram depicts when a PCC event is activated during the simulation for conventional vehicles.

The following state diagram depicts the activation of a PCC event during the simulation for xEV vehicles.

The fuel consumption of vehicles equipped with PCC option 1 & 2 and eco-roll with engine stop/start will be corrected for engine stop/start as described in engine stop/start correction.

Predictive Cruise Control Model Use-case 3

To consider predictive cruise control use-case 3, the driver model’s allowed overspeed is set to the model parameter allowed overspeed in highway sections if the vehicle supports PCC use-case 3.

Vehicle: Cross Wind Correction

VECTO offers three different modes to consider cross wind influence on the drag coefficient. It is configured in the Vehicle File. The aerodymanic force is calculated according to the following equation:

\(F_{aero}=1/2 \rho_{air}(C_{d,v}A(v_{veh})) v_{veh}^2\)

The speed dependecy of the \(C_dA\) value allows for consideration of average cross widn conditions.

Speed dependent correction (Declaration Mode)

This is the mode which is used in Declaration Mode.

The crossind correction is based on the following boundary conditions:

1 Average wind conditions: The typical conditions are defined with 3m/s of wind at a height of 4m above ground level, blowin uniformly distributed from all directions. 2 Dependency of \(C_dA\) value on yaw angle: The dependency of the \(CdA\) value on yaw angle is described by generic \(3^{rd}\) order polynomial functions of the form:

\(C_dA(\beta) - C_dA(0) = a_1\beta + a_2\beta^2 + a_3\beta^3\)

The following table gives the coefficients per vehicle type:

a1 a2 a3
rigid solo 0.013526 0.017746 -0.000666
rigid trailer, EMS 0.017125 0.072275 -0.004148
tractor semitrailer 0.030042 0.040817 -0.002130
bus, coach -0.000794 0.021090 -0.001090

In a pre-processing step VECTO calculates the function for \(C_dA\) value as a function of vehicle speed. This is done by integration of all possible directions of the ambient wind from ground level to maximum vehicle height considering the boundary layer effect based on the following formulas:

\(C_{d,v}A(v_{veh}) = \frac{1}{2 \pi v_{veh}^2 h_{veh}}\int_{\alpha = 0^{\circ}}^{\alpha = 360^{\circ}}{\int_{h=0}^{h=h_{veh}}{C_dA(\beta)\cdot v_{air}(h, \alpha)^2} \textit{d}h\ \textit{d}\alpha}\)

\(v_{air}(h) = \sqrt{(v_{wind}(h)\cdot\cos\alpha + v_{veh})^2 + (v_{wind}(h)\cdot\sin\alpha)^2}\)

\(v_{wind}(h) = v_{wind}(h_{ref})\cdot \left(\frac{h}{h_{ref}}\right)^{0.2}\)

with

\(\alpha \ldots \text{direction of ambient wind relative to the vehicle x-axis}\)

\(h \ldots \text{height above ground}\)

\(h_{ref} \ldots \text{reference heigth, 4m, for 3m/s average ambient wind}\)

\(v_{air} \ldots \text{resulting air flow velocity from vehicle speed and ambient wind}\)

\(v_{veh} \ldots \text{vehicle speed}\)

\(v_{wind} \ldots \text{velocity of ambient wind}\)

The generation of the \(C_{d,v}A(v_{veh})\) curve is demonstrated in this Excel sheet

Speed dependent correction (User-defined)

The base CdA value (see Vehicle File) is corrected with a user-defined speed dependent scaling function. A vcdv-File is needed for this calculation.

The CdA value given in the vehicle configuration is corrected depending on the vehicle’s speed and the Cd scaling factor from the input file as follows:

\(C_dA(v_{veh}) = C_dA * F_C_d(v_{veh})\)

Correction using Vair & Beta Input

The actual (measured) air speed and direction can be used to correct cross-wid influence if available. A vcdb-File is needed for this calculation. This file defines a ΔCdA value in [m²] depending on the wind angle. The driving cycle must include the air speed relative to the vehicle vair (<vair_res>) and the wind yaw angle (<vair_beta>).

The CdA value given in the vehicle configuration is corrected depending on the wind speed and wind angle (given in the driving cycle) using the input file as follows:

\(C_dA(v_veh) = C_dA + {\Delta}C_d(\beta)\)

Vehicle: Rolling Resistance Coefficient

The rolling resistance is calculated using a speed-independent rolling resistance coefficient (RRC). In order to consider that the RRC depends on the vehicle’s mass it is modelled as a function of the total vehicle mass. The total RRC is calculated in VECTO using the following equation (the index i refers to the vehicle’s axle (truck and trailer)):

\(RRC = \sum_{i=1}^{n} s_{(i)} \cdot RRC_{ISO(i)} \cdot \left( \frac{s_{(i)} \cdot m \cdot g }{w_{(i)} \cdot F_{zISO(i)} } \right)^{\beta-1}\)

with:

RRC [-] Total rolling resistance coefficient used for calculation [calculated]
s(i) [-] Relative axle load. Defined in the Vehicle File. [user input]
RRCISO(i) [-] …Tyre RRC according to ISO 28580. Defined in the Vehicle File. [user input]
w(i) [-] Number of tyres (4 if Twin Tyres, else 2). Defined in the Vehicle File. [user input]
FzISO(i) [N] Tyre test load according to ISO 28580 (85% of max. load capacity). Defined in the Vehicle File. [user input]
m [kg] Vehicle mass plus loading. [calculated]
g [m/s²] Earth gravity acceleration (constant = 9.81, Vecto 3.x: 9.80665) [constant model parameter]
β [-] Constant parameter = 0.9 [constant model parameter]

For each axle the parameters Relative axle load, RRCISO and FzISO have to be defined. Axles with twin tyres have to be marked using the respective checkbox in the Vehicle-Editor.

Engine: Fuel Consumption Calculation

The base FC value is interpolated from the stationary FC map. If necessary the base value is corrected to compensate for unconsidered auxiliary energy consumption for vehicles with Start/Stop. In Declaration Mode additional correction factors are applied.

The CO2 result for the actual mission profile is directly derived from the fuel consumption using a gravimetric CO2/FC factor.

Fuel Map Interpolation

The interpolation is based on Delaunay Triangulation  and works as follows:

  1. Triangulate the given rpm/torque/fuel points (= x,y,z)  to create a grid of triangles with each point of the map being part of at least one triangle.
  2. Find the triangle where the to-be-interpolated load point (x,y) is inside. If no triangle meets the criterion the calculation will be aborted.
  3. Calculate the z-value (= fuel) of the given x,y-point in the plane of the triangle

Delaunay Triangulation Example

Engine: Transient Full Load

The engine implements a PT1 behaviour to model transient torque build up:

\(P_{fld\ dyn_{i}} = \frac{1}{T(n_{i})+1} \cdot \left(P_{fld\ stat}(n_{i})+T(n_{i}) \cdot P_{act_{i-1}}\right)\)

with:

Vecto 3.x uses basically the same PT1 behavior to model transient torque build up. However, due to the dynamic time steps the formula is implemented as follows:

\(P_{fld\ dyn_{i}} = P_{fld\ stat}(n_i) \cdot \left(1 - e^{-\frac{t_i^*}{\mathit{PT1}}}\right)\)

where t* is computed from the dynamic full-load power in the previous simulation interval:

\(t_i^* = t_{i-1}^* + dt\)

\(t_{i-1}^* = \mathit{PT1} \cdot ln\left(\frac{1}{1 - \frac{P_{eng_{i - 1}}}{P_{fld\ stat}(n_i)}}\right)\)

Engine: Correction Factors

In declaration mode the fuel consumption is corrected as follows:

To prevent inconsistencies of regulated emissions and fuel consumption between the WHTC (hot part) test and the steady state fuel map as well as considering effects of transient engine behaviour a “WHTC correction factor” is used.

Based on the target engine operation points of the particular engine in WHTC the fuel consumption is interpolated from the steady state fuel map (“backward calculation”) in each of the three parts of the WHTC separately. The measured specific fuel consumption per WHTC part in [g/kWh] is then divided by the interpolated specific fuel consumption to obtain the “WHTC correction factors” CFurb (Urban), CFrur (Rural), CFmot (Motorway). For the interpolation the same method as for interpolation in VECTO is applied (Delauney triangulation).

All calculations regarding the brake specific fuel consumption from the interpolation as well as from the measurement and the three correction factors CFurb, CFrur, CFmot are fully implemented in the VECTO-Engine evaluation tool.

The total correction factor CFtotal depends on the mission profile and is produced in VECTO by mission profile specific weighting factors listed in the table below.

\(CF_{total} = CF_{urb} \cdot WF_{urb} + CF_{rur} \cdot WF_{rur} + CF_{mot} \cdot WF_{mot}\)

with the correction factor CFurb, CFrur, CFmot coming from the Engine, and weighting factors WFurb, WFrur, WFmot predefined in the declaration data:

Mission profile WFurb WFrur WFmot
Long haul 11% 0% 89%
Regional delivery 17% 30% 53%
Urban delivery 69% 27% 4%
Municipial utility 98% 0% 2%
Construction 62% 32% 6%
Citybus 100% 0% 0%
Interurban bus 45% 36% 19%
Coach 0% 22% 78%

In order to balance the trade-off between emissions and fuel consumption during cold and hot starting conditions an additional balancing factor \(CF_{C/H}\) is determined from the overall specific fuel consumption over the cold start and hot start WHTC test. Additional correction factors considered are regarding the net calorific value of the fuel (\(CF_{NCV}\)) and exhaust after-treatment systems (\(CF_{RegPer}\)). This values are part of the output from the engine component tool.

\(NCV_{stdEngine}\): Net calorific value as defined as reference value for engine testing (Pt. 5.3.3.1 of Annex V), see Fuel properties

\(NCV_{stdVECTO}\): Net calorific value defined as reference value for vehicle CO2 certification, see Fuel properties

The WHTC-corrected fuel consumption is then calculated with: \(FC_{final} = FC \cdot CF_{total} \cdot CF_{C/H} \cdot CF_{RegPer} \cdot \frac{NCV_{stdEngine}}{NCV_{stdVECTO}}\)

In engineering mode a single correction is applied by Vecto. The fuel consumption interpolated from the FC map is multiplied by the engineering correction factor.

\(FC_{final} = FC \cdot CF_{Engineering}\)

Dual Fuel Engine

VECTO supports to simulate vehicles equipped with dual-fuel engines, i.e. two different fuels are used simulateously. Therefore, the engine model contains a second fuel comsumption map and VECTO interpolates the fuel consumtion from both consumption maps. In the .vmod and .vsum files the consumption of every fuel is reported. The CO2 emissions are te sum of CO2 emissions from both fuels.

In case a WHR system is used with a dual-fuel vehicle the WHR map shall be provided in the fuel consumption map of the primary fuel.

Torque and Speed Limitations

The torque and speeds in the powertrain can be limited by different components such as the gearbox, the electric motor or the combustion engine, depending on the powertrain configuration.

Some additional limits can be defined in the vehicle configuration as described below.

Combustion engine limitations / Transmission Limiations

The engine’s maximum speed and maximum torque may be limited by either the gearbox (due to mechanical constraints) or the vehicle control. Engine torque limitations are modeled by limiting the engine full-load curve to the defined maximum torque, i.e., the original engine full-load curve is cropped at the defined maximum torque for a certain gear. Limits regarding the gearbox’ maximum input speed are modeled by intersecting (and limiting) the upshift line with the max. input speed. In the last gear, where no upshifts are possible, the engine speed is limited to the gearbox’ maximum input speed.

Gear shift polygons are calculated by VECTO based on the overall (i.e. from gearbox and vehicle control) cropped engine fullload curve.

In Engineering Mode, speed and torque limits can be defined and will be effective for every gear.

In Declaration Mode, the following rules restrict the limitations of engine torque:

Transmission Input-Speed Limitations

  • Applicable for every gear

Transmission Torque Limitations

  • For higher 50% of gears (i.e., gears 7 to 12 for a 12-gear transmission):
    • Transmissions max torque > 90% of engine max torque: max. torque limitation not applicable (VECTO extrapolates loss-maps)
    • Transmissions max torque <= 90% of engine max torque: max. torque limitation applicable
  • For lower 50% of gears (i.e., gears 1 to 6 for a 12-gear transmission):
    • Transmission torque limit is always applicable

Vehicle defined Torque Limitations

  • For higher 50% of gears (i.e., gears 7 to 12 for a 12-gear transmission):
    • Torque limit > 95% of engine max torque: max. torque limitation not applicable (VECTO extrapolates loss-maps)
    • Torque limit <= 90% of engine max torque: max. torque limitation applicable
  • For lower 50% of gears (i.e., gears 1 to 6 for a 12-gear transmission):
    • Torque limit is not applicable

Electric Motor Limiations

The electric motor’s maximum drive and maximum recuperation curve can be overridden in the vehicle. Therefore, the same map for maximum drive and maximum recuperation needs to be provided. Such a limit directly overrides the eletric motors model parameters.

Vehicle Propulsion Limitations

For hybrid electric vehicles the electric machine may provide additional torque to the powertrain and thus cause higher accelerations than a conventional vehicle. To limit such boosting by the electric motor.

The input is the additional torque the electric motor is allowed to boost in addition to the ICE over ICE speed.

Note: this boosting torque has to be provided from 0 rpm up to the max. ICE speed. The angular speed refers to the gearbox input shaft.

Example 1: No boosting

The blue curve shows the ICE’s full-load curve and the gray line represents the electric motors max drive torque.

If the electric motor shall not be allowed to provide additional torque beyond the ICE’s full-load curve the input for the boosting limitation looks as follows:

n [rpm] , T_drive [Nm]
0       , 0
2500    , 0

For speeds below idle speed the full-load torque available from the ICE equals the ICE full-load torque at engine idling speed due to the modeling of the clutch behavior during vehicle starts.

Example 2:

In this example the electric motor is allowed to provide torque in addition to the combustion engine (in this example 100Nm). The boosting limitation for this example looks as follows:

n [rpm] , T_drive [Nm]
0       , 100
2500    , 100

For speeds above approx. 1700 rpm, the propulsion torque limit is limited by the electric motor’s max drive curve as the electric motor cannot provide the allowed 100 Nm at this high angular speed.

Engine Fuel Consumption Correction

The final fuel consumption is corrected in a post-processing to reflect systems not directly modeled in VECTO (e.g. electric waste heat recovery sysmtes) or to account for systems not active all the time for different reasons (e.g., engine stop-start).

Engine Stop/Start Correction

As the energy demand of auxiliaries is modeled as an average power demand over the whole simulated cycle, the demand of certain auxiliaries during engine-off periods needs to be compensated during engine-on periods. This is done using the Engine-Line approach.

When either the driver model (eco-roll, engine stop/start) or the hybrid controller decides to turn off the combustion engine, it is fully off, i.e. the fuel consumption is 0 and no auxiliary power is provided. In this phases the “missing” auxiliary demand is balanced in separate colums for the cases a) the ICE is really off, and b) the ICE would be on. This allows for an accurate correction of the fuel consumption taking into account that ESS is in reality not active in all possible cases due to e.g. auxiliary power demand, environmental conditions, etc.

A general goal is that the actual auxiliary demand matches the target auxiliary demand over the cycle. So in case the ICE is off, some systems still consume electric energy but no electric energy is generated during ICE-off phases. Or in case of bus auxiliaries the total air demand is pre-calculated and thus leading to an average air demand over the cycle. During ICE-off phases, however, no compressed air is generated. This ‘missing’ compressed air is corrected in the post-processing.

A utility factor (UF) considers that the ICE is not off in all cases. Therefore the fuel consumption for compensating the missing auxiliary demand consists of two parts. The first part considers the fuel consumption required for the ‘missing’ auxiliary demand if the ICE is really off. Here the according auxiliary energy demand is multiplied by the utility factor and the engine line. The second part considers the fuel consumption in case the ICE would not be turned off. Here the ‘missing’ auxiliary energy demand is multiplied by (1 - utility factor) and the engine line and the idle fuel consumption is added for time periods the ICE would be on.

For the post-processing two different utility factors are considered. One for ICE-off phases during vehicle standstill and one for ICE-off phases during driving.

ICE Start

\(\textrm{E\_ICE\_start} = \sum{\textrm{P\_ICE\_start} \cdot dt}\)

\(\textrm{FC\_ICE\_start} = \textrm{E\_ICE\_start} \cdot k_\textrm{engline}\)

Mechanical Auxiliaries

\(\textrm{E\_aux\_ESS\_mech\_ICEoff\_standstill} = \sum_{\forall \textrm{v\_act}_i = 0}{\textrm{P\_aux\_ESS\_mech\_ICE\_off} \cdot dt}\)

\(\textrm{E\_aux\_ESS\_mech\_ICEoff\_driving} = \sum_{\forall \textrm{v\_act}_i > 0}{\textrm{P\_aux\_ESS\_mech\_ICE\_off} \cdot dt}\)

\(\textrm{E\_aux\_ESS\_mech\_ICEon\_standstill} = \sum_{\forall \textrm{v\_act}_i = 0}{\textrm{P\_aux\_ESS\_mech\_ICE\_on} \cdot dt}\)

\(\textrm{E\_aux\_ESS\_mech\_ICEon\_driving} = \sum_{\forall \textrm{v\_act}_i > 0}{\textrm{P\_aux\_ESS\_mech\_ICE\_on} \cdot dt}\)

\[ \begin{align*} \textbf{\textrm{FC\_ESS}} =\, & \textrm{FC\_ICE\_start} + \\ & \textrm{E\_aux\_ESS\_mech\_ICEoff\_standstill} \cdot k_\textrm{engline} \cdot \textrm{UF}_\textrm{standstill} + \\ & (\textrm{E\_aux\_ESS\_mech\_ICEon\_standstill} \cdot k_\textrm{engline} + \textrm{FC}(n_\textrm{idle}, 0) \cdot \textrm{t\_ICEoff\_standstill}) \cdot (1 - \textrm{UF}_\textrm{standstill}) \\ & \textrm{E\_aux\_ESS\_mech\_ICEoff\_driving} \cdot k_\textrm{engline} \cdot \textrm{UF}_\textrm{driving} + \\ & (\textrm{E\_aux\_ESS\_mech\_ICEon\_driving} \cdot k_\textrm{engline} + \textrm{FC}(n_\textrm{idle}, 0) \cdot \textrm{t\_ICEoff\_driving}) \cdot (1 - \textrm{UF}_\textrm{driving}) \end{align*} \]

Bus Auxiliaries Correction – Electric System

The bus auxiliaries electric system correction is used for conventional vehicles with ESS and buses with smart electric system in the same way.

\(\textrm{E\_BusAux\_ES\_consumed} = \sum{\textrm{P\_BusAux\_ES\_consumed} \cdot dt}\)

\(\textrm{E\_BusAux\_ES\_gen} = \sum{\textrm{P\_BusAux\_ES\_gen} \cdot dt}\)

\(\Delta\textrm{E\_BusAux\_ES\_mech} = \begin{cases} 0 & \textrm{if Alternator type is none} \\ \frac{\textrm{E\_BusAux\_ES\_consumed} - \textrm{E\_BusAux\_ES\_gen}}{\textrm{AlternatorEfficiency} \cdot \textrm{AlternatorGearEfficiency}} & \textrm{otherwise} \end{cases}\)

\(\textbf{\textrm{FC\_BusAux\_ES}} = \Delta\textrm{E\_BusAux\_ES\_mech} \cdot k_\textrm{engline}\)

Note: In case the alternator is simulated without alternator, the power generated by the alternator is always 0 and the auxiliaries are supplied from the high-voltage REESS via the DC/DC converter. In this case, no correction for the electric system needs to be applied because the energy is either taken from the REESS already during the simulation or corrected via DCDC_missing (see below).

Bus Auxiliaries Correction – Electric System Supply from REESS

\(\textrm{E\_DCDC\_missing} = \textrm{P\_DCDC\_missing} \cdot dt\)

\(\textrm{E\_DCDC\_missing\_mech} = \textrm{E\_DCDC\_missing} / \textrm{DCDC\_ConverterEfficiency} / \eta_{\textrm{EM}_\textrm{chg}}\)

\(\textbf{\textrm{FC\_DCDCMissing}} = \textrm{E\_DCDC\_missing\_mech} \cdot k_\textrm{engline}\)

Bus Auxiliaries Correction – Pneumatic System

For the pneumatic system the goal of the post-processing correction is that the correct amount of compressed air is generated, even when the ICE is off. As the average air demand is calculated with an estimated cycle driving time, the first step is to correct the air demand using the actual cycle driving time. The missing (or excessive) amout of air is transferred into mechanical energy demand using \(k_\textrm{Air}\). This value depicts the delta energy demand for a certain delta compressed air. \(k_\textrm{Air}\) is derived from two points. on the one hand the compressor runs in idle mode, applying only the drag load and producing no compressed air and the second point is that the compressor is always on, applying the always-on mechanical power demand and generating the maximum possible amount of compressed air. The mechanical energy is then corrected using the engineline (below).

\(\textrm{E\_busAux\_PS\_drag} = \sum_{\textrm{Nl\_busAux\_consumed}_i = \textrm{Nl\_busAux\_gen}_i}{\textrm{P\_busAux\_PS\_drag}\cdot dt}\)

\(\textrm{E\_busAux\_PS\_alwaysOn} = \sum_{\textrm{Nl\_busAux\_consumed}_i = \textrm{Nl\_busAux\_gen}_i}{\textrm{P\_busAux\_PS\_alwaysOn} \cdot dt}\)

\(\textrm{Nl\_alwaysOn} = \sum_{\textrm{Nl\_busAux\_consumed}_i = \textrm{Nl\_busAux\_gen}_i}{\textrm{Nl\_busAux\_gen\_max}}\)

\(k_\textrm{Air} = \frac{\textrm{E\_busAux\_PS\_alwaysOn} - \textrm{E\_busAuxPS\_drag}}{\textrm{Nl\_alwaysOn} - 0}\)

\(\textrm{CorrectedAirDemand} = \textrm{[Calculate Air demand with actual cycle time]}\)

\(\textrm{AirGenerated} = \sum{\textrm{Nl\_busAux\_PS\_gen}}\)

\(\Delta\textrm{Air} = \textrm{CorrectedAirDemand} - \textrm{AirGenerated}\)

\(\textrm{E\_busAux\_PS\_corr} = \Delta\textrm{Air} \cdot k_\textrm{Air}\)

\(\textrm{FC\_BusAux\_PS\_AirDemand} = \textrm{E\_busAux\_PS\_corr} \cdot k_\textrm{engline}\)

\(\textrm{FC\_BusAux\_PS\_Drag\_ICEoff\_driving} = \textrm{P\_PS\_drag}(n_\textrm{idle}) \cdot k_\textrm{engline} \cdot \textrm{t\_ICEoff\_driving} \cdot (1 - \textrm{UF}_\textrm{driving})\)

\(\textrm{FC\_BusAux\_PS\_Drag\_ICEoff\_standstill} = \textrm{P\_PS\_drag}(n_\textrm{idle}) \cdot k_\textrm{engline} \cdot \textrm{t\_ICEoff\_standstill} \cdot (1 - \textrm{UF}_\textrm{standstill})\)

\[ \begin{align*} \textbf{\textrm{FC\_BusAux\_PS}} =\, & \textrm{FC\_BusAux\_PS\_AirDemand} + \\ & \textrm{FC\_BusAux\_PS\_Drag\_ICEoff\_driving} + \\ & \textrm{FC\_busAux\_PS\_Drag\_ICEoff\_standstill} \\ \end{align*} \]

Bus Auxiliaries Correction – Aux Heater

The power demand for an additional fuel-fired heater is calculated in the post-processing. The HVAC steaty state model calculates the heating demand (weighted sum of different climatic conditions) and based on the engine’s average waste heat over the cycle the power demand for the aux heater is calculated. The fuel consumption for the aux heater is only added for the primary fuel:

\(E_\textrm{ice,waste heat} = \sum_\textrm{fuels} FC_\textrm{final,sum}(fuel) * NCV_\textrm{fuel}\)

\(\overline{P}_\textrm{ice,waste heat} = E_\textrm{ice, waste heat} / t_\textrm{cycle}\)

\(\textrm{E\_auxHeater} = \textrm{HVACSSM}_\textrm{AuxHtr}(\overline{P}_\textrm{ice,waste heat}) * t_\textrm{cycle}\)

\(\textbf{\textrm{FC\_BusAux\_AuxHeater}} = \textrm{E\_auxHeater} \cdot \textrm{NCV}_\textrm{main fuel}\)

Waste Heat Recovery Systems

\(\textrm{E\_WHR\_mech} = \sum{\textrm{P\_WHR\_mech} \cdot dt}\)

\(\textrm{E\_WHR\_el} = \sum{\textrm{P\_WHR\_el} \cdot dt}\)

\[ \textrm{E\_WHR\_el\_mech} = \begin{cases} \textrm{E\_WHR\_el} / \textrm{AlternatorEfficiency} & \textrm{if conventional truck} \\ \textrm{E\_WHR\_el} / \eta_{\textrm{EM}_\textrm{chg}} & \textrm{if bus with ES connected to REES and smart alternator} \\ \textrm{E\_WHR\_el} / \textrm{BusAlternatorEfficiency} & \textrm{otherwise} \end{cases} \]

\(\textbf{\textrm{FC\_WHR}} = - (\textrm{E\_WHR\_mech} + \textrm{E\_WHR\_el\_mech}) \cdot k_\textrm{engline}\)

Hybrid Vehicles: REESS SoC Correction

If the REESS Soc at the end of the simulation is higher than the initial SoC the correction is done according to:

\[ \textbf{\textrm{FC\_SoC}} = -\frac{\Delta\textrm{E\_REESS} \cdot k_\textrm{engline}}{\eta_{\textrm{EM}_\textrm{chg}} \cdot \eta_{\textrm{REESS}_\textrm{chg}}} \]

If the REESS Soc at the end of the simulation is lower than the initial SoC the correction is done according to:

\[ \textbf{\textrm{FC\_SoC}} = - \Delta\textrm{E\_REESS} \cdot k_\textrm{engline} \cdot \eta_{\textrm{EM}_\textrm{dischg}} \cdot \eta_{\textrm{REESS}_\textrm{dischg}} \]

\(\eta_{\textrm{REESS}_\textrm{chg}} = \frac{\textrm{E\_REESS\_INT\_CHG}}{\textrm{E\_REEES\_T\_CHG}}\)

\(\eta_{\textrm{REESS}_\textrm{dischg}} = \frac{\textrm{E\_REESS\_INT\_DISCHG}}{\textrm{E\_REEES\_T\_DISCHG}}\)

Corrected Total Fuel Consumption

The final fuel consumption after all corrections are applied is calcualted as follows:

\[ \begin{align*} \textrm{FC\_FINAL} =\;& \textrm{FC\_ModSum} \;+ \\ & \textrm{FC\_ESS} \;+ \\ & \textrm{FC\_DCDCMissing} \;+ \\ & \textrm{FC\_BusAux\_PS} \;+ \\ & \textrm{FC\_BusAux\_ES} \;+ \\ & \textrm{FC\_WHR} \;+ \\ & \textrm{FC\_BusAux\_AuxHeater} \;+ \\ & \textrm{FC\_SoC} \\ \end{align*} \]

Engine-Line Approach

The total fuel consumption is corrected in a post-processing step according to the engine-line approach. Therefore, for every engine operating point where the engine is on and has a positive fuel consumption the fuel consumption is plotted over the engine power. The slope (k) of the linear regression of the fuel consumption is used to compute the additional fuel that is needed for the energy demand during engine-off periods and engine starts.

Engine Waste Heat Recovery Systems

VECTO is able to consider energy recovered from the combustion engine’s waste heat either as mechanical power or as electrical power. The following options for waste-heat recovery system are availabel:

The first type of WHR systems do not require a dedicated simulation as this is already covered in the combustion engine’s fuel consumption map. The output power at the crankshaft is usually higher when such a WHR system is active, or for a certain measurement setpoint (torque and engine speed) the fuel consumption is lower compared to an engine without waste-heat recovery system.

For the other two types of WHR systems where the recovered energy is not directly connected to the engine’s crankshaft the generated power needs to be provided in the combustion engine’s fuel consumption map (see .vmap file. The final fuel consumption is corrected for the latter two WHR systems via the engine-line approach, taking into account the accumulated power generated by the WHR system during the cycle. In case of an electrical WHR system the electric energy is converted to the equivalent mechanical energy that the combustion engine “does not need to provide” considering the alternator’s efficiency.

The power generated by a WHR system is interpolated from the engine’s WHR map (part of the fuel consumption map) multiplied by a correction factor similar to the WHTC correction for the fuel consumption.

Fuel Properties

FuelType Tanksystem FuelDensity [kg/m3] CO2 per FuelWeight [kgCo2/kgFuel] NCV_stdEngine [kJ/kg] NCV_stdVecto [kJ/kg] Note
Diesel CI 836 3.13 42700 42700
Ethanol CI 820 1.81 25700 25400
Petrol PI 748 3.04 41500 41500
Ethanol PI 786 2.10 29100 29300
LPG PI 3.02 46000 46000
NG PI compressed 2.69 45100 48000 H-Gas
NG PI liquefied 2.77 45100 49100 EU mix 2016/2030

Specifications are based on an analysis (2018) performed by CONCAWE/EUCAR and shall reflect typical fuel on the European market. The data was in the context of the study: Well-To-Wheels Analysis Of Future Automotive Fuels And Powertrains in the European Context – Heavy Duty vehicles (doi:10.2760/100379)

VECTO Input for CNG/LNG Vehicles

Currently only the fuel type ‘NG PI’ for the engine certification is allowed according to Regulation (EU) 2017/2400. For LNG vehicles, therefore, the engine fuel type has to be set to ‘NG PI’ and at the vehicle level NgTankSystem has to be set to ‘liquefied’. For CNG vehicles the same engine fuel type is provided but NgTankSystem has to be set to ‘compressed’.

Transmission Losses

Every transmission component (gearbox, angledrive, axlegear, …) uses the following formula for calculating the torques at input and output side of the component:

\(T_{output} = (T_{input} - T_{loss}) * r_{gear}\)

with:

The following components are accounted as transmission components (see Powertrain and Components Structure for a complete overview over all components in the powertrain):

Gearbox: AT Gearbox Model

Vecto supports both, AT gearboxes with serial torque converter and AT gearboxes with power split. Internally, both gearbox types are simulated using a power train architecture with the torque converter in series.

Automatic transmission with torque converter in series
Automatic transmission with parallel torque converter

In the input data Gearbox File only the mechanical gears need to be specified. Depending on the gearbox type (AT-S or AT-P) Vecto adds the correct virtual ‘torque converter gear’.

For AT gearbox with serial torque converter, the torque converter uses the same ratio and mechanical losses as the first gear (and second, depending on the gear ratios), and adds the torque converter.

For AT gearboxes using power split the torque converter characteristics already takes the transmission ratio and mechanical losses into account. Hence, Vecto sets the ratio for the mechanical gear to 1 without additional losses.

The .vmod file for vehicles with AT gearboxes contains an additional column that indicates if the torque converter is locked or not.

Gearshift losses for AT Gearboxes

For AT gearboxes the losses during a power-shift are modeled according to the following equations

Basic assumptions

  • Only power-shifts with positive power at gearbox output side are considered.
  • Both upshifts and downshifts with positive power at gearbox output side have to be considered.
  • The power at gearbox output side is assumed to be constant during a power-shift

Power-shift loss computation

Model parameters: shift time (\(t_s\)), inertia factor (\(f_I\))

Engine speed, clutch speed during power-shift

\(T_{PS,loss} = |T_{GBX,in} * \Delta\omega_F| * t_s / dt\)

\(\Delta\omega_I = \omega_{engine,1} - \omega_{engine,2}\)

\(\Delta\omega_F = (\omega_{engine,1} - \omega_{engine,1^*}) / 2\)

Gear Shift Model

This VECTO version contains a new shift strategy called EffShift.

The shift strategy is on a first level based on gearshift lines for upshift and downshift (similar to the classic VECTO gearshift strategy). Additionally “Efficiency shifts” can be triggered between the shift lines, if the fuel efficiency (g/kWh cardan) in a candidate gear is better than in the current gear. In order to cover a large range of the engine map with the “Efficiency shifts”, the area between the downshift and upshift line has to be of sufficient size. Hence, the shift lines are defined as shown in the figure below, with the downshift line (green) to the left and the up-shift line (red) to the right. Due to the superposition of the gear-shift lines with the EffShift algorithm as described below the upshift line is not relevant for upshifts in most cases.

The points P1 to P4 are calculated according as follows:

The definition of the upshift line depends on the transmission type: for AMT, the pre-shift engine speed is considered for the upshift line and for AT the post-shift engine speed is used. Additionally, the demanded acceleration to be available after a gearshift is reduced compared to the current acceleration: This is done for engine speeds between \(n_{T98h}\) and \(n_{P98h}\). This shall reduce reving up the engine during full-load accelerations. The demanded acceleration is calculated as follows:

\(a_{demand} = a_{act} * a_{red}\) for \((n_{act} > n_{T98h})\)

\(a_{red} = 1+ (\textrm{AccelerationFactorNP98h} - 1) / (n_{P98h} - n_{T98h}) * (n - n_{T98h})\) for \((n_{act} > n_{T98h})\)

Shift Strategy: AMT Gearshift Rules

This section describes the gearshift rules for automatic manual transmission models. When a gearshift is triggered, gears may be skipped.

The Effshift control algorithm differentiates between the shift rules:

For the EffShift model general shift conditions apply regardless of the shift rule, with exception of emergency shifts, these have always priority.

The general gearshift conditions for downshifting are:

The general gearshift conditions for upshifting are:

The general shift conditions are checked first in the shift algorithm. The following table lists the generic values for the parameters used in the declaration mode settings of current version of the AMT Effshift model.

Parameter Value
\(t_{between shifts}\) 2 [s]
Downshift delay 6 [s]
Upshift delay 6 [s]
Allowed gear range 2
RatioEarlyDownshift, RatioEarlyUpshift 24
Rating current gear 0.97
\(T_{reserve}\) 0

Emergency shifts

Emergency shifts depend on the current gear and the engine speed. The shifting rules for emergency shifts have been adopted from the “Classic” gearshift strategy in VECTO. In case of application of emergency rule no skipping of gears is applied.

Shift to neutral, if:

  • Current gear = 1 and
  • \(n_{eng} < n_{idle}\)

Downshift conditions:

  • Current gear > 1 and
  • \(n_{eng} < n_{idle}\)

Upshift conditions:

  • Current gear < highest gear
  • \(n_{eng} < n_{95h}\)

Polygon shifts

The second level of the gearshift algorithm is the polygon shift rule. If the current operating point is outside of the shift polygons, the polygon shift rule applies:

Downshift behaviour:

  • If the operating point (Teng, neng) is left the downshift line, shift to the next lower gear

Upshift behaviour:

  • If the operating point (Teng, neng) is right to the upshift line, shift to the highest gear which is right to the downshift line and below the full load torque considering similar engine power output.

It should be noted, that there is no skip gears at downshifting in the polygon shift mode.

Efficiency shifts

The efficiency shift rule is added on top of the polygon shift rule. The EffShift strategy allows gear shifts if the current engine operating point is inbetween the gearshift lines and a certain threshold above the engine’s drag curve and the combined fuel efficiency considering engine and gearbox characteristics in the candidate gear is better than in the current gear. Therefore the fuel consumption of the current gear and the gears within an allowed gear shift range (parameter allowed +/- gears) is calculated. For AMT transmissions, the current operating point is used for this efficiency evaluation. Since, the velocity drop due to traction interruption is not relevant for this evaluation as this operating point only occurs for a short period of time. Efficiency shifts are only allowed below a certain gear ratio (gearbox + axle) to prevent frequent gear changes in the very lowest gears.

\(FC_{gear}=min(FC_{gear + i}) \forall i \in \textrm{Allowed gear range}\)

Additionally the following boundary conditions must be fulfilled for an efficiency upshift to happen:

  • \(i_{gear + axle} \leq \textrm{RatioEarlyUpshift}\)
  • Not left to downshift line
  • \(1-P_{eng}(candidate gear) / P_{eng,max}(candidate gear) > T_\textrm{reserve}\) (\(T_\textrm{reserve}\) is set to 0 for efficiency shifts)
  • \(P_{eng,act } \leq P_{eng,post_shift}\) This condition is based on the assumption that sufficient power for the current acceleration is available in the next gear. The check for sufficient power in a candidate gear considers the velocity drop during traction interruption.
  • \(FC_{gear} < FC_{current gear} * \textrm{RatingFactor}\)

For an efficiency downshift following conditions are met:

  • \(i_{gear + axle} \leq \textrm{RatioEarlyDownshift}\)
  • Not right upshift line
  • \(1-P_{eng}(next gear) / P_{eng,max} > T_{reserve}\) (\(T_{reserve}\) is set to 0 for efficiency shifts)
  • \(FC_{gear} < FC_{current gear} * \textrm{RatingFactor}\)

Shift Strategy: APT Gearshift Rules

For APT gearboxes gear skipping is only allowed for transmissions with more than 6 gears. Otherwise, the gears are shifted strictly sequentially:

The model structure for shifting between “locked” gears for APT does not differ from the AMT algorithm. That means that the shift logic also differentiates between emergency shifts, polygon gearshifts and efficiency shifts which are processed in the same sequence.

In addition rules for shifting from torque converter (TC) to locked gears apply. These rules are described below. First step in the algorithm is the check of general conditions.

General gearshift conditions for downshifting:

General gearshift conditions for the upshift in a locked gear (1C -> 1L, 2C ->2L, L ->L):

Parameters used in the APT Effshift model:

Parameter Value
t_(between shifts) 1.8 [s]
Downshift delay 6 [s]
Upshift delay 6 [s]
Allowed gear range (skip of gears) Total number of mechanical gears ≤ 6: 1, else 2
CCMinAcceleration 0.1 [m/s²]
CLMinAcceleration 0.1 [m/s²]
UpshiftMinAcceleration 0.1 [m/s²]
RatioEarlyDownshift 24
RatioEarlyUpshift 24
Rating current gear 0.97
T_reserve 0

For triggering gear shifts between gears “1C” and “2C” (if applicable for a certain transmission) the same function as in the VECTO Classic model is applied.

Upshift between TC gears (1C -> 2C):

With:

and

Emergency shifts

The Emergency shift strategy for APT transmission looks as follows.

Downshift:

  • \(n_{eng} < n_{idle}\)

Upshift (all conditions are met):

  • \(n_{eng} > min(n_{max,gear}, n_{95h})\)
  • gear < maxGear
  • \(a_{estimated} > 0\)
  • TC = locked
  • Gear + 1 is above downshift line

Polygon shifts

The Polygon shift rule for APT works on the same principle as for AMT. But, as already mentioned above the calculation of the upshift line is based on the post-shift engine speed. If the general requirements are fulfilled and it is not an emergency shift, the algorithm of the EffShift model uses the polygon shift rule. In this regard, two different cases related to a downshift are distinguished.

Conditions for downshift case 1:

  • Operation point (Teng, neng) before downshift is left to downshift line.

Conditions for downshift case 2 (all conditions have to be met):

  • DriverAction = Accelerating
  • \(a_{act} < 0\)
  • \(v_{veh} < v_{target} - 10km/h\)
  • Locked gear
  • DeltaFullLoad(gear – 1) < DeltaFullLoad(gear)

Conditions for an upshift:

  • Operation point (Teng, neng) before upshift is right to upshift line.

  • \(a_{estimated} > min(\textrm{UpshiftMinAcceleration}, \textrm{DriverAcceleration})\) (if TC is locked)

    Or \(a_{estimated} > min(\textrm{CLUpshiftMinAcceleration}, \textrm{DriverAcceleration})\) (if TC is unlocked)

Efficiency shifts

The efficiency shift algorithm for APT works similar to the AMT algorithm in case of locked gears. In order to depict differences in gear selection which result from the different shifting sequences (APT: powershift, AMT: traction interruption) the operation points used for rating of fuel efficiency and for checking the power requirements in a candidate gear are calculated differently. More specifically, this assessment looks 0.8 seconds into the future, so that a relevant operating point after the shift is considered.

For up-shifts from a torque converter gear (“C”) to a locked gear (“L”) the estimated engine speed in the locked gear has to be above a certain threshold. This threshold depends on the engine’s load stage and the road gradient.

Shift rules for L -> L shifts (Efficiency shifts):

The search algorithm for the next gear is as follows:

\(FC_{gear} = min(FC_{gear + i}) \forall i \in \textrm{Allowed gear range}\)

Additionally the candidate gear has to fulfil the boundary conditions below for an efficiency upshift.

  • \(i_{gear + axle} \leq \textrm{RatioEarlyDownshift}\)
  • Not left to downshift line
  • \(1 - (P_{eng} / P_{eng,max}) > T_{reserve} (\)T_{reserve}$ is set to 0)
  • \(FC_{gear} < FC_{current gear} * \textrm{Rating current gear}\)

For an efficiency downshift following conditions are met for the potential gear:

  • \(i_{gear + axle} \leq \textrm{RatioEarlyDownshift}\)
  • Not right upshift line
  • \(1 - (P_{eng} / P_{eng,max}) > T_{reserve}\) (\(T_{reserve}\) is set to 0)
  • \(FC_{gear} < FC_{current gear} * \textrm{Rating current gear}\)

Shift rules for C -> L shifts (Efficiency shifts):

The used algorithm can be summarised as follows:

Definitions:

Parameter Unit Description
torque ratio [%] current engine torque / maximum engine torque at actual engine speed
a_min [ m/s²] available acceleration at actual engine torque for maximum loaded vehicle
a_max [m/s²] available acceleration at actual engine torque for empty vehicle
a_curr [m/s²] available acceleration at actual engine torque for current vehicle mass

In each time-step a target post-shift engine speed from the shift strategy is calculated in a three step approach: * The current engine load stage is determined based on current torque ratio and a set of hysteresis thresholds * For the current engine load stage and the current slope each a rpm value is interpolated from a parameter table * The final value for target post-shift engine speed is interpolated for the current value of a_curr from the results of the previous step

If the estimated engine speed after a C -> L shift is calculated to be equal or higher than the target engine speed as calculated above, the gear shift is initiated. This approach in combination with the proposed parameters as shown below reflects the strategy that shifts from C -> L are performed with absolute priority in order to minimise driveline losses from torque converter operation.

Boundary values between engine load stages (values for torque ratio in [%]) (relevant for C -> L shifts)

Load stage 1<->2 2<->3 3<->4 4<->5 5<->6
Hysteresis upper 19.70 36.34 53.01 69.68 86.35
Hysteresis lower 13.70 30.34 47.01 63.68 80.35

Matrix with target post-shift engine speed offset above idling speed (values in rpm, relevant for C -> L shifts)

engine load stage a_max, slope +5% a_max, slope 0% a_max, slope -5% a_min, slope +5% a_min, slope 0% a_min, slope -5%
1 90 120 165 90 120 165
2 90 120 165 90 120 165
3 90 120 165 90 120 165
4 90 120 165 110 140 185
5 100 130 175 120 150 195
6 110 140 185 130 160 205

Shift Strategy: MT Gearshift Rules

This section describes the gearshift rules for manual transmission models. When a gearshift is triggered, gears may be skipped for (see Gearbox: Gear Shift Model).

Shift Polygons in Declaration Mode (According to ACEA Whitebook 2016)

1. Computation of Characteristic Points

2. Definition of Shift Lines

3. Exception 1: Margin to Max-Torque line (Downshift)

Note: Line L1 is shiftet parallel so that it satisfies the max-torque margin condition, not intersected.

4. Exception 2: Minimal Distance between Downshift and Upshift Lines

5. Final Gearshift Lines (Example)

If the gearbox defines a maximum input speed for certain gears the upshift line may further be intersected and limited to the gear’s maximum input speed.

Upshift rules

  • If the engine speed is higher than the gearbox maximum input speed or engine n_{95h} speed (whichever is lower)
  • If all of the following conditions are met:
    • The vehicle is not decelerating AND
    • Engine operation point (speed and torque) is above (right of) the upshift line AND
    • The acceleration in the next gear is above a certain threshold if the driver is accelerating, i.e., acceleration_nextGear > min(Min. acceleration threshold, Driver acceleration) AND
    • The last gearshift was longer than a certain threshold (Declaration Mode: 2s) ago AND
    • The last downshift was longer than a certain threshold (Declaration Mode: 10s) ago

Downshift

  • If the engine speed is lower than the engine’s idle speed
  • If all of the following conditions are met:
    • Engine operation point (speed and torque) is below (left of) the downshift line AND
    • The last gearshift was longer than a certain threshold (Declaration Mode: 2s) ago AND
    • The last upshift was longer than a certain threshold (Declaration Mode: 10s) ago

Shift parameters

  • Gearshift lines
  • Engine idle speed
  • Gearbox max. input speed
  • Engien n_{95h} speed
  • Min. time between two consecutive gearshifts.
  • Min. time for upshift after a downshift
  • Min. time for downshift after an upshift
  • Min. acceleration in next gear

Torque Converter Model

The torque converter is defined as (virtual) separate gear. Independent of the chosen AT gearbox type (serial or power split), Vecto uses a powertrain architecture with a serial torque converter. The mechanical gear ratios and gears with torque converter are created by Vecto depending on the gearbox type and gear configuration.

While the torque converter is active engine torque and speed are computed based on TC characteristic.

Torque converter characteristics file (.vtcc)

The file is described here.

This file defines the torque converter characteristics as described in VDI 2153:

  • Speed Ratio (\(\nu\)) = Output Speed / Input Speed
  • Torque Ratio (\(\mu\)) = Output Torque / Input Torque
  • Input Torque (\(T_{ref}(\nu)\)) is the input torque (over ν) for a specific reference engine speed (see below).

The Input Torque at  reference engine speed is needed to calculate the actual engine torque using this formula:

\(T_{in} = T_{ref}(\nu) \cdot ( \frac{n_{in}}{n_{ref}} )^{2}\)

\(\mu(\nu) = \frac{T_{out}}{T_{in}}\)

with:

  • Tin = engine torque [Nm]
  • Tref(ν) = reference torque at reference rpm (from .vtcc file) [Nm]
  • nin = engine speed [1/min]
  • nref = reference rpm [1/min] (see below)

The torque converter characteristics must also be defined for speed ratios greater than one (ν>1) in order to calculate overrun conditions or engine drag (torque<0).

Note: The torque converter characteristics must not contain parts where either the torque ratio or the input torque are constant!

In declaration mode, the torque converter for drag points is automatically appended by VECTO. Input data with a speed ratio ≥ 1 are skipped.

For Power Split transmissions, where the torque converter characteristics already includes the gearbox losses and transmission ratio, the generic drag points are adapted according to the following equations:

\(\nu_{PS} = \nu / ratio_i\)

\(\mu_{PS} = \mu \cdot ratio_i\)

In engineering mode the drag points for the torque converter can be specified. If so, the input data has to cover at least the speed ratio up to 2.2.

If the torque converter characteristics for drag are not specified, the generic points are appended as described above for declaration mode.

The torque converter has a separate Shift Polygon which defines the conditions for switching from torque converter gear to locked gear.

Auxiliaries

In Declaration mode the auxiliaries are pre-defined and the power demand is defined based on the vehicle category and mission. For every type of auxiliary (fan, steering pump, HVAC, electrig system, pneumatic system) the user can select a technology from a given list.

In Engineering mode the auxiliary power demand for the following states of the vehicle can be defined:

  • ICE On
  • Vehicle driving, ICE off
  • Vehicle standstill, ICE off

If the ICE is on, the auxiliary power demand is directly applied to the combustion engine. In case the ICE is off, the according power demand is balanced in the modal data and the fuel consumption is corrected in post processing.

Bus Auxiliaries

Note: Bus auxiliaries in declaration mode are only available via XML input files.

The general approach for bus auxiliaries is that depending on the simulated driving cycle, number of passengers and selected auxiliary technologies the average power demand is calculated and applied during simulation. In case of smart auxiliaries (smart air compressor or smart alternator) the smart systems are only active during braking events if there is enough exessive power to provide the increased power demand for the smart systems. This reduces the amount of mechanical braking power required. Thus, during braking events the smart air compressor may produce more compressed air than required on average and the smart alternator may generate more electric power than required on average. The final fuel consumption is corrected for the excessive compressed air volume and electric energy in a post processing step.

Engine Cooling Fan

The power demand for the engine cooling fan depends on the selected technology of the cooling fan.

Steering Pump

The power demand of the steering pump can either be electrical or mechanical. The actual demand depends on the selected technology, vehicle dimensions and number of steered axles.

Pneumatic System

The air demand depends on the one hand on the cycle (number of braking events, number of stops, number of kneeling events, etc) and the vehicle configuration. Depending on the compressor technology a generic compressor map is used to calculate the power demand for a certain air demand.

Electric System

Depending on the vehicle group and mission profile a generic electric load is applied. Certain technologies can be selected in the input (LED lamps).

HVAC

Model Parameters:

  • Bus body
    • Length \(l_\textrm{Bus}\)
    • Width \(b_\textrm{Bus}\)
    • Height \(h_\textrm{Bus}\)
    • Double decker
    • Floor type (low floor, raised floor)
  • Auxiliary heater power
  • HVAC system configuration
  • Number of passengers
  • Fuel saving technologies
  • Environmental contidions map

The environmental conditions map contains a list of environmental conditions (environmental temperature, solar factor) and a weighting factor. The power demand for the HVAC system (separated into mechanical and electrical power demand) is calculated for every environmental contition in the map and summed up with the according weighting factor.

Calculation of HVAC Power Demand

\(P_\textrm{HVAC,mech,sum} = \sum_\textrm{env} w_\textrm{env} * min(P_\textrm{HVAC,mech}(T_\textrm{env}, S_\textrm{env}) * (1 - \textrm{TechBenefitsMech}), P_\textrm{HVAC,max}) / \textrm{COP}\)

\(P_\textrm{HVAC,el,sum} = \sum_\textrm{env} w_\textrm{env} * min(P_\textrm{HVAC,el}(T_\textrm{env}, S_\textrm{env}) * (1 - \textrm{TechBenefitsEl}), P_\textrm{HVAC,max}) / \textrm{COP} + P_\textrm{ventilation,heating}(T_\textrm{env}, S_\textrm{env}) * (1 - \textrm{TechBenefitsElHeatingVent}) + P_\textrm{ventilation,cooling}(T_\textrm{env}, S_\textrm{env}) * (1 - \textrm{TechBenefitsElCoolingVent})\)

\(P_\textrm{HVAC,mech}(T, S) = \left\{ \begin{array}{ll} 0 & : T < 17^{\circ}C\\ 0 & : \textrm{electric compressor}\\ min( P_\textrm{HVAC}(T, S, T_\textrm{low}) , P_\textrm{HVAC}(T, S, T_\textrm{high}(T))) & : P_\textrm{HVAC}(T, S, T_\textrm{low}) > 0 \;\textrm{and}\; P_\textrm{HVAC}(T, S, T_\textrm{high}(T)) > 0 \\ 0 & : \textrm{otherwise} \end{array} \right.\)

\(P_\textrm{HVAC,el}(T, S) = \left\{ \begin{array}{ll} 0 & : T < 17^{\circ}C\\ 0 & : \textrm{mechanical compressor}\\ min( P_\textrm{HVAC}(T, S, T_\textrm{low}) , P_\textrm{HVAC}(T, S, T_\textrm{high}(T))) & : P_\textrm{HVAC}(T, S, T_\textrm{low}) > 0 \;\textrm{and}\; P_\textrm{HVAC}(T, S, T_\textrm{high}(T)) > 0 \\ 0 & : \textrm{otherwise} \end{array} \right.\)

\(P_\textrm{ventilation,heating}(T_\textrm{env}, S_\textrm{env}) = \left\{ \begin{array}{ll} V_\textrm{Bus} * r(\textrm{true}) * 0.56 Wh/m^3 & : P_\textrm{HVAC}(T, S, T_\textrm{low}) < 0 \;\textrm{and}\; P_\textrm{HVAC}(T, S, T_\textrm{high}(T)) < 0 \\ 0 & : \textrm{otherwise} \end{array} \right.\)

\(P_\textrm{ventilation,cooling}(T_\textrm{env}, S_\textrm{env}) = \left\{ \begin{array}{ll} V_\textrm{Bus} * r(\textrm{false}) * 0.56 Wh/m^3 & : T_\textrm{env} \geq 17^{\circ}C \;\textrm{and}\; P_\textrm{HVAC}(T, S, T_\textrm{low}) > 0 \;\textrm{and}\; P_\textrm{HVAC}(T, S, T_\textrm{high}(T)) > 0 \\ 0 & : \textrm{otherwise} \end{array} \right.\)

\(r(\textrm{heating}) = \left\{\begin{array}{ll} 7 \;1/h & : \textrm{HVAC Configuration 1 \& 2}\\ 10 \;1/h & : \textrm{heating} \;\textrm{and}\; \textrm{HVAC Configuration 3 -- 9} \\ 20 \;1/h & : \textrm{HVAC Configuration 3 -- 9} \\ \end{array} \right.\)

\(T_\textrm{low} = 18^{\circ}C\)

\(T_\textrm{high}(T_\textrm{env}) = \left\{\begin{array}{ll} max(23^{\circ}C, T_\textrm{env} - 3^{\circ}C) & : \textrm{Low floor bus}\\ 23^{\circ}C & : \textrm{otherwise} \end{array} \right.\)

\(P_\textrm{HVAC}(T_\textrm{env}, S, T_\textrm{calc}) = Q_\textrm{Wall}(T_\textrm{env}, T_\textrm{calc}) + P_\textrm{Passenger}(T_\textrm{env}) + P_\textrm{Solar}(T_\textrm{env}, S)\)

\(Q_\textrm{Wall}(T_\textrm{env}, T_\textrm{calc}) = (T_\textrm{env} - T_\textrm{calc}) * A_\textrm{BusSurface} * U\)

\(P_\textrm{Passenger}(T_\textrm{env}) = \#_\textrm{Passenger} * \left\{\begin{array}{ll} 50\; W & : T_\textrm{env} < 17^{\circ}C\\ 80\; W & : \textrm{otherwise} \end{array} \right.\)

\(P_\textrm{Solar}(T_\textrm{env}, S) = S * A_\textrm{Windows} * G * S_\textrm{clouding}(T_\textrm{env}) * 0.25\)

\(S_\textrm{clouding}(T_\textrm{env}) = \left\{\begin{array}{ll} 0.65 & : T_\textrm{env} < 17^{\circ}C\\ 0.8 & : \textrm{otherwise} \end{array} \right.\)

\(U = \left\{\begin{array}{ll} 4\; W/Km^2 & : \textrm{Low floor bus}\\ 3\; W/Km^2 & : \textrm{Raised floor bus} \end{array} \right.\)

\(G = 0.95\)

\(V_\textrm{Bus} = l_\textrm{HVAC} * b_\textrm{Bus} * h_\textrm{Bus}\)

\(A_\textrm{BusSurface} = 2 * (l_\textrm{HVAC} * b_\textrm{Bus} + l_\textrm{HVAC} * h_\textrm{Bus} + b_\textrm{Bus} * h_\textrm{Bus})\)

\(A_\textrm{Window} = l_\textrm{HVAC} * h_\textrm{Windows} + A_\textrm{Front\&Rear}\)

\(l_\textrm{HVAC} = \left\{\begin{array}{ll} 2 * 1.2 \;m & : \textrm{HVAC Configuration 2}\\ l_\textrm{Bus} & : \textrm{otherwise} \\ \end{array} \right.\)

\(h_\textrm{Windows} = \left\{\begin{array}{ll} 2.5 \;m & : \textrm{Double Decker}\\ 1.5 \;m & : \textrm{Single Decker} \end{array} \right.\)

\(A_\textrm{Front\&Rear} = \left\{\begin{array}{ll} 8 \;m^2 & : \textrm{Double Decker}\\ 5 \;m^2 & : \textrm{Single Decker} \end{array} \right.\)

\(P_\textrm{HVAC,max} = P_\textrm{HVAC,max,passenger} + P_\textrm{HVAC,max,driver}\)

\(P_\textrm{HVAC,max,passenger} = \textrm{Lookup}_\textrm{passenger}(\textrm{HVAC Configuration}, \textrm{driving cycle}) * V_\textrm{passenger}\)

\(V_\textrm{passenger} = l_\textrm{internal} * h_\textrm{internal} * b_\textrm{Bus}\)

\(l_\textrm{internal} = \left\{\begin{array}{ll} 2 * l_\textrm{Bus} & : \textrm{low floor} \;\textrm{and}\; \textrm{double decker}\\ l_\textrm{Bus} & : \textrm{low floor} \;\textrm{and}\; \textrm{single decker}\\ 1.5 * l_\textrm{Bus} & : \textrm{raised floor} \;\textrm{and}\; \textrm{double decker} \;\textrm{and}\; \#_\textrm{passengers lower deck} > 6\\ l_\textrm{Bus} + 2.4 \;m & : \textrm{raised floor} \;\textrm{and}\; \textrm{double decker} \;\textrm{and}\; \#_\textrm{passengers lower deck} \leq 6\\ l_\textrm{Bus} & : \textrm{raised floor} \;\textrm{and}\; \textrm{single decker}\\ \end{array} \right.\)

\(h_\textrm{internal} = \left\{\begin{array}{ll} 1.8 \;m & : \textrm{double decker} \\ h_\textrm{Bus} - 0.5 \;m & : \textrm{single decker} \;\textrm{and}\; \textrm{raised floor} \\ h_\textrm{Bus} & : \textrm{single decker} \;\textrm{and}\;\textrm{low floor} \end{array} \right.\)

\(P_\textrm{HVAC,max,driver} = \textrm{Lookup}_\textrm{driver}(\textrm{HVAC Configuration}, \textrm{driving cycle})\)

Aux Heater Power

\(P_\textrm{HVACSSM,auxHtr}(\overline{P}_\textrm{ice,waste heat}) = \sum_\textrm{env} w_\textrm{env} * P_\textrm{auxHtr}(T_\textrm{env}, S_\textrm{env}, \overline{P}_\textrm{ice,waste heat}) * 0.2 * 0.75)\)

\(P_\textrm{auxHtr}(T, S, P_\textrm{wasteHeat}) = \left\{ \begin{array}{ll} |max( P_\textrm{additionalHeating}(T, S, T_\textrm{low}, P_\textrm{wasteHeat}) , P_\textrm{additionalHeating}(T, S, T_\textrm{high}(T), P_\textrm{wasteHeat}))| & : P_\textrm{HVAC}(T, S, T_\textrm{low}) < 0 \;\textrm{and}\; P_\textrm{HVAC}(T, S, T_\textrm{high}(T)) < 0 \\ 0 & : \textrm{otherwise} \end{array} \right.\)

\(P_\textrm{additionalHeating}(T, S, T_\textrm{calc}, P_\textrm{wasteHeat}) = \left\{ \begin{array}{ll} P_\textrm{HVAC}(T, S, T_\textrm{calc}) * (1 - \textrm{TechBenefitsFuelHeater})) + P_\textrm{wasteHeat} & : P_\textrm{HVAC}(T, S, T_\textrm{calc}) * (1 - \textrm{TechBenefitsFuelHeater})) < 0 \;\textrm{and}\; P_\textrm{HVAC}(T, S, T_\textrm{calc}) * (1 - \textrm{TechBenefitsFuelHeater})) < -P_\textrm{wasteHeat} \\ 0 & : \textrm{otherwise} \end{array} \right.\)

In Engineering Mode the electrical and mechanical power demand for the electric system, the pneumatic system and the HVAC can be provided.

Electric System

Current Demand Engine On
Demand of the electric system when the ICE is on. The current is multiplied with the nominal voltage of 28.3V.
Current Demand Engine Off Driving
Demand of the electric system when the ICE is off and the vehicle is driving. The current is multiplied with the nominal voltage of 28.3V.
Current Demand Engine Off Standstill
Demand of the electric system when the ICE is off and the vehicle is at standstill. The current is multiplied with the nominal voltage of 28.3V.
Alternator Efficiency
The electric power demand is divided by the alternator efficiency to get the mechanical power demand at the crank shaft
Alternator Technology
The “conventional alternator” generated exactly the electric power as demanded by the auxiliaries. The “smart alternator” may generate more electric power than needed during braking phases. The exessive electric power is stored in a battery. In case “no alternator” is selected (only available for xEV vehicles) the electric system is supplied from the high voltage REESS via a DC/DC converter.
Max Recuperation Power
In case of a smart alternator, defines the maximum electric power the alternator can generate during braking phases.
Useable Electric Storage Capacity
In case of a smart alternator, defines the storage capacity of the battery. In case the battery is not empty, the electric auxiliaries are supplied from the battery. Excessive electric energy from the smart alternator during braking phases is stored in the battery.
Electric Storage Efficiency
This efficiency is applied when storing electric energy from the alternator in the battery.
ESS supply from HEV REESS
If selected, the low-voltage electric auxiliaries can be supplied from the high voltage REESS via the DC/DC converter. Needs to be selected in case “no alternator” is chosen as alternator technology. In case of a smart alternator, the low-voltage battery is used first and if empty the energy is drawn from the high voltage system.

Pneumatic System

Compressor Map
Compressor map file defining the mechanical power demand and the air flow depending on the compressor speed.
Average Air Demand
Defines the average demand of copressed air througout the cycle.
Compressor Ratio
Defines the ratio between the air compressor and combustio engine
Smart Air Compressor
If enabled, the air compressor may generate excessive air during braking events. The air consumed and generated are corrected in post processing.

HVAC System

Mechanical Power Demand
Power demand of the HVAC system directly applied at the crank shaft
Electric Power Demand
Electric power demand of the HVAC system. This is added to the current demand of the electric system
Aux Heater Power
Maximum power of the auxiliary heater
Average Heating Demand
Heating demand for the passenger compartment. This demand is primary satisfied from the combustion engines waste heat. In case the heating demand is higher, the auxiliary heater may provide additional heating power. The fuel consumption of the aux heater is corrected in post processing.

Pwheel-Input (SiCo Mode)

For verification tasks it is possible to manually input the power at wheels (Pwheel) which is normally calculated via longitudinal dynamics. In this case VECTO only calculates the losses between wheels and engine and adds auxiliary power demand. This mode is active as soon as Pwheel, Gear and Engine Speed are defined in the driving cycle.

Requirements

  • Driving Cycle must include t, Pwheel (Pwheel), Gear (Gear) and Engine Speed (n), see Driving Cycle (.vdri) format.
  • The driving cycle must be time-based.

Example driving cycle with Pwheel input.

<t> <Pwheel> <gear> <n>
1 0.0 0 560.0
2 0.0 0 560.0
3 14.0 1 593.2
4 51.9 1 705.5

PTO

VECTO supports the simulation of PTO related components and losses in the powertrain. Structurally this consists of 2 components (PTO transmission, PTO consumer) and 3 different kind of losses (transmission, idling, cycle).

Structural Overview of PTO Components

Losses in the PTO “Transmission” part (blue)

This is considered by constant power consumption as a function of the PTO type. The power consumption is added in all vehicle operation conditions, due to VECTO not differentiating between clutch open/closed and gear engaged/disengaged. The PTO type is configurable in the Vehicle Editor. The exact values are shown in the following table:

Technology Power Loss [W]
None 0
only the drive shaft of the PTO - shift claw, synchronizer, sliding gearwheel 50
only the drive shaft of the PTO - multi-disc clutch 1000
only the drive shaft of the PTO - multi-disc clutch, oil pump 2000
drive shaft and/or up to 2 gear wheels - shift claw, synchronizer, sliding gearwheel 300
drive shaft and/or up to 2 gear wheels - multi-disc clutch 1500
drive shaft and/or up to 2 gear wheels - multi-disc clutch, oil pump 3000
drive shaft and/or more than 2 gear wheels - shift claw, synchronizer, sliding gearwheel 600
drive shaft and/or more than 2 gear wheels - multi-disc clutch 2000
drive shaft and/or more than 2 gear wheels - multi-disc clutch, oil pump 4000

Idling losses of the PTO “Consumer” (red)

The idling losses are a function of speed as determined by the DIN 30752-1 procedure. If the PTO transmission includes a shifting element (i.e. declutching of consumer part possible) the torque losses of the consumer in VECTO input shall be defined with zero. This is only used outside of PTO cycles, since the PTO cycles already include these losses. The idling losses are defined as a lossmap dependend on speed which is configurable in the Vehicle Editor. The file format is described in PTO Idle Consumption Map.

Cycle losses during the PTO cycle of the PTO “Consumer” (red)

A specific PTO cycle (time-based, engine speed and torque from PTO consumer as determined by the DIN 30752-1 procedure) is simulated during vehicle stops labelled as “with PTO activation”. The execution of the driving cycle stops during this time and the pto cycle is executed. Afterwards the normal driving cycle continues.

Power consumption in the PTO transmission part added to power demand from the PTO cycle. The cycle is configurable in the Vehicle Editor and follows the file format described in PTO-Cycle (.vptoc). The timings in the PTO cycle get shifted to start at 0.

Behavior During PTO Driving Cycles

A PTO cycle can only be activated during a stop phase in the driving cycle. When the PTO cycle is activated VECTO exhibits the following behavior: Half of the stop time is added before the pto cycle, and the other half is added afterwards. If the halved stop times are still longer than 3 seconds, they get divided even further to 3 intervals in order to achieve a more appealing visualization in the output (falling down, low baseline, rising again). It is recommended to have a stop time of at least 2 seconds.

The following image shows the behavior of running PTO cycles during a normal driving cycle:

  1. Normal driving behavior.
  2. The first half of the stop phase begins, the vehicle stops and the engine speed goes down to idle speed (if there is enough time).
  3. The PTO cycle continues from the last engine speed in stop phase and sets it to the engine speed of the first entry in the PTO cycle.
  4. After the PTO cycle ends, the second half of the stop phase begins and the engine speed again goes to idle speed (if enough time passes).
  5. After the stop phase the normal driving behavior starts again - the vehicle drives off.

Additional PTO activations in Engineering mode

In engineering mode additonal PTO activations are available to simulate different types of municipal vehicles. It is possible to add a certain PTO load during driving while the engine speed and gear is fixed (to simulate for example roadsweepers), or to add PTO activation while driving (to simulate side loader refuse trucks for example). In both cases the PTO activation is indicated in the driving cycle.

The .vmod file file contains additional columns with the PTO power applied during driving (P_PTO_RoadSweeping, P_PTO_DuringDrive) and is also included in P_PTO_CONSUM. In the .vsum file the energy demand for both PTO modes is provided in the columns E_aux_PTO_RoadSweeping and E_aux_PTO_DuringDrive.

Roadsweeper

PTO activation mode 2 simulates PTO activation while driving at a fixed engine speed and gear. The minimum engine speed and working gear is entered in the PTO tab of the Vehicle editor.

PTO mode 2 activation is indicated in the driving cycle by a value of ‘2’ in the PTO column for as long as the PTO shall be active. Additionally, the PTO power applied during driving has to be provided in the driving cycle in the column P_PTO. The actual PTO power demand applied is interpolated from the entries in the driving cycle over distance.

If the defined gear and minimum engine speed leads to a higher vehicle speed than provided in the driving cycle the target speed is increased accordingly. If the vehicle speed with the defined gear and minimum engine speed is below the target speed, the vehicle is simulated with the original target speed.

Sideloader

PTO activation mode 3 simulates a time-based PTO activation while driving. Therefore, a separate PTO cycle (.vptor) containing the PTO power over time has to be provided. The start of PTO activation is indicated with a ‘3’ in the ‘PTO’ column of the driving cycle.

In case the vehicle stops and the PTO cycle is not finished the PTO power demand is applied during standstill as well. A warning is shown in the message panel.

Electric Motor

The electric motor is modeled by basically 4 map files:

The first two curves are read from a .vemp file (see Electric Motor Max Torque File (.vemp)). The drag curve is provided in a .vemd file (see Electric Motor Drag Curve File (.vemd)) and the electric power map in a .vemo file (see Electric Motor Map (.vemo)).

During the simulation the maximum drive torque, maximum generation torque, and electric power map is interpolated for both voltage levels and the actual value used is interpolated between both voltage levels with the current internal voltage of the REESS.

The drag curve is used to add additional drag to the powertrain in case the electric motor is turned off.

The convention for all input files is that positive torque values drive the vehicle while negative torque values apply additional drag and generate electric power.

The follwing picture shows the signals used in VECTO and provided in the .vmod file. The VECTO convention is that positive torque adds additional drag to the drivetrain. Thus, if the electric motor propells the vehicle it applies negative torque.

Electric Motor Model

The VECTO component for the electric motor contains the electric motor itself which is connected via a transmission stage to the drivetrain. The ratio and efficiency of the transmission stage can be defined in the vehicle model.

The naming convention for the signals is that ‘X’ denotes the position of the EM in the powertrain. P_X_… denotes signals related to the drivetrain speed while P_X-em_… denotes signals to the electric motor shaft.

P_X_in = P_X_out + P_X_mech

P_X_mech = P_X-em_mech + P_X_transm_loss

P_X-em_mech = P_X-em_mech_elmap + P_X-em_inertia

P_X-em_mech_elmap = P_X-em_el + P_X-em_loss

P_X-em_mech_elmap = n_X-em * T_X-em_map

P_X-em_el = PowerMap(n_X-em, T_X-em_map)

P_X_loss = P_X_mech - P_X-em_el

Electric Power Map Interpolation

The electric power demand of the electric machine is not directly interpolated in the provided power map. Due to the characteristic of the map (increasing electric power with both, torque and speed) the resulting delaunay map may cause deviations from the assumed electric power demand depending on how the triangles are actually added to the delaunay map.

Therefore, the electric power map is converted to a “virtual torque loss” map similar to the transmission loss-maps. For every entry in the electric power map, the virtual torque loss is calculated as follows:

\(T_\textrm{loss,em-map} = \frac{P_\textrm{el}(n_\textrm{em}, T_\textrm{em}) - n_\textrm{em} \cdot T_\textrm{em}}{n_\textrm{em}}\)

From the tuple \((n_\textrm{em}, T\textrm{em}, T_\textrm{loss,em-map})\) a Delaunay map is created. In the simulation the actual electric power is then calculated as follows:

\(P_\textrm{el}(n_\textrm{em}, T_\textrm{em}) = \textrm{Delaunay}_\textrm{EM-Map}(n_\textrm{em}, T_\textrm{em}) \cdot n_\textrm{em} + n_\textrm{em} \cdot T_\textrm{em}\)

Thermal De-Rating

The electric machine can be overloaded for a certain period. In addition to the maximum drive and generation torque (which already is in overload condition) the mechanical power the electric machine can generate is required.

The basic principal of the thermal de-rating is as follows: based on the continuous power and the angular velocity for the continuous power as well as the maximum overload time a thermal energy buffer is calculated. During the simulation the difference between the current losses in the electric machine and the losses at the continuous power operating point are integrated over time. If this value reaches the capacity of the thermal energy buffer the electric machine can only deliver the specified continuous power until the thermal energy buffer goes below a certain threshold.

\(E_\textrm{th,buf} = (P_\textrm{loss,ovl} - P_\textrm{loss,cont}) \cdot t_\textrm{ovl}\)

\(P_\textrm{loss,ovl} = n_\textrm{T,ovl} \cdot T_\textrm{ovl} - P_\textrm{map, el}(T_\textrm{ovl}, n_\textrm{T, ovl})\)

\(P_\textrm{loss,cont} = n_\textrm{T,cont} \cdot T_\textrm{cont} - P_\textrm{map, el}(T_\textrm{cont}, n_\textrm{T, cont})\)

In every simulation step the losses of the electric machine are accumulated:

\(E_{\textrm{ovl,} i + 1} = E_{\textrm{ovl,} i} + (P_\textrm{loss, i} - P_\textrm{loss,cont}) \cdot dt\)

\(P_\textrm{loss, i} = T_\textrm{em, mech} \cdot n_\textrm{em} - P_\textrm{map, el}(T_\textrm{em, mech}, n_\textrm{em})\)

If \(E_\textrm{ovl, i}\) reaches the overload capacity \(E_\textrm{th,buf}\) the power of the electric machine is limited to the continuous power until \(E_\textrm{ovl,i}\) goes below the overload capacity multiplied by the thermal overload recovery factor. Then the maximum torque is available again.

RESS

Battery

The battery model uses the following model parameters:

  • Capacity of the battery pack
  • Maximum current for charging and discharging over the state of charge
  • Minimum state of charge
  • Maximum state of charge
  • Voltage of the battery pack over state of charge
  • Internal resistance of the battery pack over state of charge. The internal resistance can either be constant over the pulse duration or depending on the length of the pulse duration (see .vbatr Battery Internal Resistance)

The voltage curve over state of charge is described in Battery Internal Voltage File (.vbatv) and the internal resistance curve over state of charge is described in Battery Internal Resistance File (.vbatr). The file format of the maximum current map is described in Battery Max Current Map (.vimax).

During the simulation the battery’s state of charge must always be between the minimum and maximum SoC threshold.

The maximum discharge current is further limited by the battery’s internal resistance:

\(I_\textrm{disch,max} = \frac{U(\textrm{SoC})}{4 * R_i(\textrm{SoC})}\)

Time-dependent Internal Resistance

If the internal resistance is provided for different pulse durations, the actual internal resistance is interpolated between the provided resistance values with the current pulse duration. No extrapolation is applied. For pulses below Ri_2, Ri_2 is applied, for pulse durations longer then Ri_20 (or Ri_120 if provided) this value is used. The pulse duration is reset every time the current changes its sign.

Modular Battery System

VECTO allows to connect multiple batteries togehter to a single battery system. Therefore, every battery has assigned a stream identifier. All batteries with the same stream identifier are connected in series. All battery strins are then connected in parallel.

The following picture shows 4 batteries in series (3x Bat A + Bat B) and Bat C parallel to this. So two different streams need to be defined.

All batteries of a string of the mudular battery system are aggregated to a single “big battery”. In the example above, BigBattery1 consists of (Bat A, Bat A, Bat A, Bat B), and BigBattery2 consists of (Bat C). Nevertheless, the state of charge is calculated for each battery module independently.

The capacity of a BigBattery is the capacity of the smalles of all modules on a string. The maximum current of a BigBattery is also the lowest maximum current of all modules on a string. The open circuit voltage is the sum of all modules on a string and the internal resistancee is also the sum of all modules on a string.

The maximum charge and discharge power of the whole REESS is the sum of the maximum charge/discharge power of all BigBatteries in the system. The actual power demand is distributed to the BigBatteries as follows:

\(P_i = \frac{C_i}{\sum_{j}{C_j}} \cdot \delta_i \cdot P_\textrm{act}\)

\(\delta_i = 1 - \textrm{sgn}(P_\textrm{act})\frac{\textrm{SoC}_i - \textrm{SoC}_\textrm{avg}}{\textrm{SoC}_\textrm{avg}}\)

\(\textrm{SoC}_\textrm{avg} = \frac{\sum_j{\textrm{SoC}_j \cdot C_j}}{\sum_j{C_j}}\)

\(\textrm{SoC}_i = \frac{\min_{B \in BB}(\textrm{SoC}_B \cdot C_B)}{C_i}\)

\(P_i\) … Power for BigBattery i

\(C_i\) … Nominal capacity of BigBattery i.

\(P_\textrm{act}\) … actual power demand

In case a BigBattery reaches its max. power, the power for this BigBattery is limited to its max. power and then the power distribution is re-calculated with the remaining power demand.

To update the state of charge of each battery, the current \(I_i\) for each BigBattery is computed from the following equation:

\(P_i = (U_i + R_i \cdot I_i) \cdot I_i\)

And then the power demand for every single battery can be computed from

\(P_{B_i} = (U_{B_i} + R_{B_i} \cdot I_i) \cdot I_i\)

Super Capacitor

The super capacitor model uses the following model parameters:

  • Capacity of the SuperCap in Farad
  • Internal resistance
  • Minimum voltage
  • Maximum voltage
  • Maximum current charging
  • Maximum current discharging

The values of maximum charging current and maximum discharging current need to be positive!

Hybrid Control Strategy

The basic principle of the hybrid control strategy is to evaluate different options of operating modes, i.e., different splits of the demanded torque at the wheels among the electric motor and the combustion engine. For every option a cost function is calculated, taking onto account the required electric energy and the fuel consumption. Out of the examined operating modes the best option, i.e, the option with the lowest cost value is selected.

The hybrid control is located in the simulated power train right after the wheels. Hence, the hybrid control strategy gets as input the torque and angular velocity at the wheels as input.

Model Parameters

Hybrid Strategy

  • MinICEOnTime
  • MinSoC
  • MaxSoC
  • TargetSoC
  • EquivalenceFactor
  • Cost Factor SoC Exponent \(e\)
  • AuxReserveTime
  • AuxReserveChargeTime

Gear Selection

  • MinTimeBetweenGearshifts
  • DownshiftAfterUpshiftDelay
  • UpshiftAfterDownshiftDelay
  • AllowedGearRangeUp
  • AllowedGearRangeDown

Evaluation of different options

Note: The convention is that for all powertrain components (except te ICE) a positive torque loss means an additional drag while a negative torque loss means the component contributes to propel the vehicle. So all passive components can only apply positive torque losses and only active components such as electric motors can propel the vehicle which means it has a negative torque loss.

The variable u is used to identify the different evaluated options. The value of u denotes the factor how much of the torque at the output shaft of the electric motor is applied by the electric motor. A u value of -1 thus means the electric motor provides the full torque demanded at its output shaft and the torque at the input shaft is 0. A positive value of u means that the electric motor acts as generator and applies a torque demand in addition.

In case the driver’s action is to accelerate the vehicle, the hybrid control strategy performs the following steps to obtain a list of potential configurations:

  1. Issue a dry-run request with the currently demanded torque and angular speed.

    For this request the electric motor is switched off. The purpose of this request is to get the resulting power demand at the combustion engine and more importantly, to get the minimum/maximum torque the electric motor can provide and the maximum/minimum torque the combustion engine can provide. This is also a viable configuration and thus added to the list of evaluated configurations

  2. Evaluate options where the electric motor contributes to propel the vehicle.

    1. Iterate over all negative u values with a certain step size (typically 0.1) up to u_maxDrive u_maxDrive is detemined by the torque demanded at the out shaft of the electric motor and the maximum drive torque of the electric motor – whichever is lower.
    2. If the case where the electric motor applies its maximum drive torque is not already covered by the
      iteration of u values in the previous step, calculate the maximum drive configuration explicitly
    3. If it is allowed to turn off the electric motor or the electric motor can propel during gear shifts, search the torque the electric motor needs to provide so that the torque at the gearbox input gets 0. This means the electric motor provides more torque than demanded in order to overcome losses of components later in the powertrain. If this torque value is within the limits of the electric motor, calculate the corresponding u value and add this option to the list of evaluated configurations.
  3. Evaluate options where the electric motor acts as generator and applies additional drag losses.

    1. Iterate over all positive u values with a certain step size (typically 0.1) up to the electric motor’s maximum generation torque.
    2. For vehicles of configuration P2 evaluate the configuration where the electric motor’s generation torque equals the torque demanded at the electric motor’s output shaft (i.e., the torue at the electric motor’s input shaft is 0) if it is allowed to turn of the ICE.
    3. For vehicles of configuration P3 and P4 search for the torque the electric motor has to apply as a generator so that the resulting torque at the combustion engine is 0. If this torque value is within the limits of the electric motor, calculate the corresponding u value and add this option to the list of evaluated configurations.

In case of a coast or roll action (e.g. during look-ahead coasting dur during traction interruption) the electric motor is turned off.

In case the driver performs a brake aktion the following options are considered

  1. In case of vehicle configurations P3 or P4, or vehicle configuration P2 and the gearbox is engaged:
    1. If the combustion engine is on and the torque demand at the combustion engine is above the drag curve, switch the electric motor off.
    2. If the torque demand at the combustion engine is below the drag curve, evaluate all options as described for the case the driver accelerates (see above).
  2. In case of vehicle configuration P2 and the gearbox is not engaged, turn the electric motor off

Gear selection

For hybrid vehicles it is not possible to decouple gear selection from the electric motor’s operating point because the gearshift strategy only considers the çombustion engine’s operating point. In some situations it is more efficient to select a different gear which results in an overall more efficient operating point (considering both, electric motor and combustion engine).

The hybrid strategy combines the main ideas of the EffShift gearshift strategy and the selection of the best operating point.

Depending on the last gearshift the allowed gear range for upshifts and downshifts is determined. For every allowed gear all possible settings of the hybrid powertrain as describe above are evaluated.

Cost Function

A cost value is calculated for every evaluated solution described above. In case the configurration results in an invalid operating point the cost value is set to invalid. Reasons for invalid configurations are that the engine operating point is outside the shift polygons, the engine speed is too high or too low, the electric power demand is too high or too low, the battery’s SoC would go below the \(\textrm{SoC}_{low}\) threshold, etc.

If a configuration is not valid because for example the ICE speed is too high or too low, or the torque demand is too high, or too low the corresponding value of the cost function is set to ‘NaN’ (not a number) and thus the total score is invalid. In addition, certain flags indicating why a certain configuration is considered invalid are set. These flags are used for the selection of a hybrid configuration to be used as described below. *Note: the calculated score may be a valid number but certain ignore flags may be set. For example if the engine speed is slightly too high or the battery SoC is

For all valid configurations a cost function is calculated which basically considers the fuel consumption and the electric power:

\(C = \sum_{i \in \textrm{Fuels}}{FC_{i} \cdot NCV_{i} \cdot dt} + f_{\textrm{equiv}} \cdot (P_\textrm{Bat} \cdot dt + C_{\textrm{Pen1}}) \cdot f_{SoC} + C_{\textrm{Pen2}}\)

  • FC is the combustion engine’s fuel consumption for the current simulation interval

  • NCV denotes the fuel’s net calorific value

  • \(P_\textrm{Bat}\) is the power drawn from the battery. Positive values denote the battery is discharged

  • \(f_\textrm{equiv}\) is the equivalence factor to compare energy from the ICE and energy from the electric system. Typically in the range of 2.5

  • \(f_\textrm{SoC}\) is a cost factor that depends on the battery’s state of charge.

  • \(C_\textrm{Pen1}\) is a penalty for starting the combustion engine. It is set to 0.1 times the energy required to ramp up the combustion engine. The ramp-up energy is calculated the same way as for the engine stop/start correction - see Advanced Driver Assistant Systems: Engine Stop/Start.

    If the combustion engine is currently off and is off in the considered configuration \(P_\textrm{Pen1}\) is set to 0.

    If the battery’s SoC is below the lower SoC threshold \(\textrm{SoC}_{low}\) then \(P_\textrm{Pen1}\) is set to 0.

  • \(C_\textrm{Pen2}\) is a penalty considering idling costs of the combustion engine, currently set to 0.

\(f_\textrm{SoC} = 1 - \left(\frac{\textrm{SoC} - \textrm{TargetSoC}}{0.5 \cdot (\textrm{SoC}_\textrm{max} - \textrm{SoC}_{min}} \right)^e + C_\textrm{SoC}\)

\(C_\textrm{SoC} = \left\{ \begin{array}{ll} \frac{C_\textrm{minSoC}}{\textrm{SoC}_\textrm{min} - \textrm{SoC}_{low}} \cdot \textrm{SoC} + p_\textrm{minSoC} - \frac{C_\textrm{minSoC}}{\textrm{SoC}_\textrm{min} - \textrm{SoC}_{low}} \cdot \textrm{SoC}_{min} : \textrm{SoC} < \textrm{SoC}_{low}\\ 0 : \textrm{otherwise} \end{array} \right.\)

\(\textrm{SoC}_\textrm{low} = \textrm{SoC}_{min} + 0.1 \cdot \left(\textrm{SoC}_{max} - \textrm{SoC}_{min}\right)\)

\(C_\textrm{minSoC} = 10\)

The following graph depicts the shape of \(f_\textrm{SoC}\) (red line) and both summands separately (blue: polynomial function, orange: C_) for a minimum SoC of 20%, maximum SoC of 80% and a target SoC of 50%;

Flags for ignoring a evaluated hybrid configuration

  • EngineSpeedTooLow: the engine speed is below the engine idle speed
  • EngineSpeedTooHigh: the engine speed is above the engine’s \(n_{95h}\) speed
  • EngineTorqueDemandTooHigh: the torque demanded from the engine is above the dynamic full-load
  • EngineTorqueDemandTooLow: the torque demanded from the engine is below the drag-torque
  • EngineSpeedAboveUpshift: the engine operating point is right of the upshift line of the current gear
  • EngineSpeedBelowDownshift: the engine operating point is left of the downshift line of the current gear
  • BatteryBelowMinSoC: the battery’s state of charge falls below the allowed minimum SoC
  • BatteryAboveMaxSoC: the battery’s state of charge exceeds the allowed maximum SoC
  • BatterySoCTooLow: the strategy may add a certain safety margin to the minimum SoC for certain reasons. Set if the SoC falls below the lower boundary \(\textrm{SoC}_\textrm{low}\)

Selection of the best option.

From the list of possible hybrid powertrain configurations with its cost value the best option is selected according to the following list of conditions. If one or many configurations match the criteria listed in a step, the first configuration is used. If no configuration matches the criteria the next step is evaluated.

  1. Select all configurations with a valid score (i.e. the score is not NaN).
    • If the vehicle speed is above the gearbox’ start speed no flag to ignore the configuration must be set.
    • If the vehicle speed is below the gearbox’ start speed (i.e. the vehicle is accelerating from standstill) the engine speed must not be too high.
    • Order the configurations by score
  2. Select all configurations with a valid score and the engine speed is valid (i.e., not too high, nor too low and within the shift lines) and order by score
  3. Select all configurations with a valid score and order by score
  4. If the driver is accelerating and in all evaluated configurations the engine’s torque demand is above the engine’s maximum torque filter the possible configurations according to the following criteria
    1. If the electric motor can propell during traction interruptions (i.e., P4 and P3 configurations) or the gearbox is engaged (P2 configuration) select all configurations where the battery SoC is within the allowed range, order the configurations by difference in gear to the current gear and then order the configurations by the mecanical torque the electric motor can provide
  5. If the driver is accelerating and in all evaluated configurations the engine’s torque demand is below the engine’s drag torque filter the possible configurations according to the following criteria. If the electric motor can propel during traction interruptions (i.e., P4 and P3 configurations) or the gearbox is engaged (P2 configuration)
    1. Select all configurations where the engine speed is valid and the battery’s SoC is within the allowed range and order the configurations by the difference in gear to the current gear and then by the mechanical torque the motor can provide
    2. Select all configurations where the battery’s SoC is within the allowed range and order the configurations by the difference in gear to the current gear and then by the mechanical torque the motor can provide
  6. If the driver is accelerating and the gearbox is engaged filter the possible configurations according to the following criteria.
    1. Select all configurations where the engine speed is not too low nor too high and order the configurations by the difference in gear to the current gear
    2. If no entries match the previous criteria order all configurations by the difference in gear to the current gear
    3. Order the configurations by the mechanical torque provided by the electric motor
  7. If the driver is braking and the gearbox is engaged select all configurations where the battery SoC is within the allowed range and order by the torque the electric motor can apply for braking

Input and Output

Vecto uses data files for input and output of data. These are stored in different formats which are listed here.

Input:

Output:

XML Job-File (Declaration Mode)

For vehicle certification the input data (vehicle data) has to be provided in XML format. Please see the following resources for more information:

XML Declaration Report

In Declaration Mode VECTO generates two reports according to the Technical Annex for vehicle certification:

  • Manufacturer Report
  • Customer Information Report

Both reports are in XML format and contain a description of the simulated vehicle and the simulation results. The format is described in the following resources:

Sample reports are distributed with the generic vehicles.

Note: For better readability and improved presentation, the XML has attached a stylesheet that allows nice rendering in web-browsers. If you open an XML report in your browser, you may be asked the credentials for the CITnet SVN server (same credentials as you need for downloading VECTO) as the CSS is hosted on CITnet.

CSV

Many data files in Vecto use CSV (Comma Separated Values) as common file format. They consist of a header which defines the columns and data entries which are separated by a comma (“,”).

In Vecto 3 the order of the columns is arbitrary if the column header matches the header definitions described in this user manual. If the column header does not match, a warning is written to the log file and the columns are parsed in the sequence as described in this manual as a fall-back.

Definition

Header: Vecto CSV needs exactly one header line with the definition of the columns at the beginning of the file.
Columns can be surrounded with “<” and “>” to mark them as identifiers (which makes them position independent). In Vecto 3.x every column is seen as identifier, regardless of “<>”.
Columns may be succeded with unit information (enclosed in “[” and ”]”) for documentation purposes.
Column Separator: , (Comma. Separates the columns of a data line.)
Decimal-Mark: . (Dot. Splits numbers into integer part and decimal part.)
Thousand-Separator: Vecto CSV does not allow a thousand-separator.
Comments: # (Number sign. Declares text coming afterwards in the current line as comment.)
Whitespace: Whitespaces between columns will be stripped away. Therefore it is possible to align the columns for better readability, if desired.

Note: All column headers are case insensitive.

Note: Unit information in the column header (enclosed in “[” and ”]”) are only information for the user. Vecto does not read the unit string nor convert between units. The values are expected to be in the units as specified in the user manual.

Following files use the csv:

Examples

Exampl 1: Acceleration Limiting File

v [km/h],acc [m/s^2]     ,dec [m/s^2]
0       ,1.01570922360353,-0.231742702878269
5       ,1.38546581120225,-0.45346198022574
10      ,1.34993329755465,-0.565404125020508
15      ,1.29026714002479,-0.703434814668512

Example 2: Driving Cycle

<s>,<v>,<grad>      ,<stop>,<Padd>,<Aux_ALT1>,<Aux_ALT2>,<Aux_ALT3>
0  ,0  ,-0.020237973,2     ,6.1   ,0.25      ,0.25      ,0.25
1  ,64 ,-0.020237973,0     ,6.1   ,0.25      ,0.25      ,0.25
2  ,64 ,-0.020237973,0     ,6.1   ,0.25      ,0.25      ,0.25
3  ,64 ,-0.020237973,0     ,6.1   ,0.25      ,0.25      ,0.25

Example 3: Transmission Loss Map

Input Speed [rpm],Input Torque [Nm],Torque Loss [Nm]
0                ,-2500            ,77.5
0                ,-1500            ,62.5
0                ,-500             ,47.5
0                ,500              ,47.5

JSON

Configuration and component files in Vecto use JSON as common file format.

Following files use JSON:

Job File

File for the definition of an job in vecto. A job contains everything what is needed to run a simulation. Can be created with the Job Editor.

Refers to other files:

Example:

{
  "Header": {
    "CreatedBy": "",
    "Date": "2020-09-07T15:36:16.4539236Z",
    "AppVersion": "3",
    "FileVersion": 8
  },
  "Body": {
    "SavedInDeclMode": false,
    "EngineOnlyMode": false,
    "VehicleFile": "Group5_HEV.vveh",
    "EngineFile": "Engine_325kW_12.7l.veng",
    "GearboxFile": "AMT_12.vgbx",
    "TCU": "AMT_12.vgbx",
    "ShiftStrategy": "TUGraz.VectoCore.Models.SimulationComponent.Impl.AMTShiftStrategy",
    "HybridStrategyParams": "Hybrid_Parameters.vhctl",
    "AuxiliaryAssembly": "Classic",
    "AuxiliaryVersion": "CLASSIC",
    "AdvancedAuxiliaryFilePath": "",
    "Aux": [],
    "Padd": 5000.0,
    "Padd_electric": 0.0,
    "VACC": "Truck.vacc",
    "EngineStopStartAtVehicleStopThreshold": 2.0,
    "EngineStopStartMaxOffTimespan": 120.0,
    "EngineStopStartUtilityFactor": 1.0,
    "EcoRollMinSpeed": 0.0,
    "EcoRollActivationDelay": 0.0,
    "EcoRollUnderspeedThreshold": 0.0,
    "EcoRollMaxAcceleration": 0.0,
    "PCCEnableSpeed": 0.0,
    "PCCMinSpeed": 0.0,
    "PCCUnderspeed": 0.0,
    "PCCOverSpeed": 5.0,
    "PCCPreviewDistanceUC1": 0.0,
    "PCCPreviewDistanceUC2": 0.0,
    "LAC": {
      "Enabled": true,
      "PreviewDistanceFactor": 10.0,
      "DF_offset": 2.5,
      "DF_scaling": 1.5,
      "DF_targetSpeedLookup": "",
      "Df_velocityDropLookup": "",
      "MinSpeed": 50.0
    },
    "OverSpeedEcoRoll": {
      "Mode": "Overspeed",
      "MinSpeed": 50.0,
      "OverSpeed": 2.5
    },
    "Cycles": [
      "LongHaul.vdri",
      "RegionalDelivery.vdri",
      "UrbanDelivery.vdri"
    ]
  }
}

VTP-Job File

File for the definition of a verification test job in vecto. A job contains everything what is needed to run a simulation. Can be created with the Verifcation Test Job Editor.

Refers to other files:

Example:

{
  "Header": {
    "CreatedBy": "VECTO 3.2",
    "Date": "2017-11-14T13:16:31.7337506Z",
    "AppVersion": "3",
    "FileVersion": 4
  },
  "Body": {
    "SavedInDeclMode": false,
    "DeclarationVehicle": "SampleVehicle.xml",
    "FanPowerCoefficients": [
      0.00000055,
      14.62,
      108.5
    ],
    "FanDiameter": 0.225,
    "Cycles": [
      "VTP-cycle.vdri"
    ]
  }
}

Vehicle File (.vveh)

File for the definition of a vehicle in vecto. Can be created with the Vehicle Editor.

Refers to other files:

Example:

{
  "Header": {
    "CreatedBy": "",
    "Date": "2020-09-07T15:36:11.4469594Z",
    "AppVersion": "3",
    "FileVersion": 10
  },
  "Body": {
    "SavedInDeclMode": false,
    "VehCat": "Tractor",
    "LegislativeClass": "Unknown",
    "CurbWeight": 8229.0,
    "CurbWeightExtra": 7500.0,
    "MassMax": 18.0,
    "Loading": 19300.0,
    "rdyn": 492.0,
    "CdCorrMode": "CdofVdecl",
    "CdCorrFile": "",
    "AxleConfig": {
      "Type": "4x2",
      "Axles": [
        {
          "Inertia": 14.9,
          "Wheels": "315/70 R22.5",
          "AxleWeightShare": 0.2,
          "TwinTyres": false,
          "RRCISO": 0.0055,
          "FzISO": 33350.0,
          "Type": "VehicleNonDriven"
        },
        {
          "Inertia": 14.9,
          "Wheels": "315/70 R22.5",
          "AxleWeightShare": 0.25,
          "TwinTyres": true,
          "RRCISO": 0.0065,
          "FzISO": 33350.0,
          "Type": "VehicleDriven"
        },
        {
          "Inertia": 19.2,
          "Wheels": "385/65 R22.5",
          "AxleWeightShare": 0.18333,
          "TwinTyres": false,
          "RRCISO": 0.0055,
          "FzISO": 41690.0,
          "Type": "Trailer"
        },
        {
          "Inertia": 19.2,
          "Wheels": "385/65 R22.5",
          "AxleWeightShare": 0.18333,
          "TwinTyres": false,
          "RRCISO": 0.0055,
          "FzISO": 41690.0,
          "Type": "Trailer"
        },
        {
          "Inertia": 19.2,
          "Wheels": "385/65 R22.5",
          "AxleWeightShare": 0.18334,
          "TwinTyres": false,
          "RRCISO": 0.0055,
          "FzISO": 41690.0,
          "Type": "Trailer"
        }
      ]
    },
    "EngineStopStart": true,
    "EcoRoll": "None",
    "PredictiveCruiseControl": "None",
    "ATEcoRollReleaseLockupClutch": false,
    "CdA": 5.3,
    "VehicleHeight": 4.0,
    "IdlingSpeed": 600.0,
    "Retarder": {
      "Type": "None",
      "Ratio": 1.0,
      "File": ""
    },
    "Angledrive": {
      "Type": "None",
      "Ratio": 0.0,
      "LossMap": ""
    },
    "PTO": {
      "Type": "None",
      "LossMap": "",
      "Cycle": ""
    },
    "TorqueLimits": {},
    "MaxDrivetrainPower": 1000.0,
    "InitialSoC": 50.0,
    "PowertrainConfiguration": "ParallelHybrid",
    "ElectricMotors": [
      {
        "Count": 1,
        "Ratio": 1.0,
        "MechanicalEfficiency": 1.0,
        "Position": "P2",
        "MotorFile": "GenericEMotor_140kW_936Nm.vem"
      }
    ],
    "Battery": {
      "NumPacks": 1,
      "BatteryFile": "GenericBattery_10kWh_658V.vbat"
    }
  }
}

Speed Dependent Cross Wind Correction Input File (.vcdv)

The file is needed for speed dependent Cross Wind Correction. The file uses the VECTO CSV format.

Example:

v_veh [km/h],Cd [-]
0           ,1.173
5           ,1.173
10          ,1.173
15          ,1.173
20          ,1.173
25          ,1.173
30          ,1.173
35          ,1.173
40          ,1.173
45          ,1.173
50          ,1.173
55          ,1.173
60          ,1.173
65          ,1.153
70          ,1.136
75          ,1.121
80          ,1.109
85          ,1.099
90          ,1.090
95          ,1.082
100         ,1.07

Vair & Beta Cross Wind Correction Input File (.vcdb)

The file is needed for Vair & Beta Cross Wind Correction. The file uses the VECTO CSV format.

Example:

beta [°],delta CdA [m^2]
0       ,0.00
1       ,0.07
2       ,0.21
3       ,0.40
4       ,0.64
5       ,0.90
6       ,1.19
7       ,1.48
8       ,1.76
9       ,2.02
10      ,2.25
20      ,3.14
40      ,3.24
60      ,-0.76
80      ,-4.76
100     ,-9.01
120     ,-15.01
140     ,-21.01
160     ,-20.86
180     ,-16.15

Retarder Loss Torque Input File (.vrlm)

This file is used to define retarder idling losses. It can be used for primary and secondary retarders and must be set in the Vehicle File. The file uses the VECTO CSV format.

Example:

Retarder Speed [1/min],Torque Loss [Nm]
0                     ,10
100                   ,10.02
200                   ,10.08
300                   ,10.18
...

Engine File (.veng)

File for the definition of an engine in Vecto. Can be created with the Engine Editor.

Refers to other files:

Example:

{
  "Header": {
    "CreatedBy": "",
    "Date": "2019-12-03T16:57:31.6048929Z",
    "AppVersion": "3",
    "FileVersion": 5
  },
  "Body": {
    "SavedInDeclMode": false,
    "ModelName": "325kW 12.7l Engine",
    "Displacement": "12740",
    "IdlingSpeed": 600.0,
    "Inertia": 5.1498,
    "Fuels": [
      {
        "WHTC-Urban": 0.0,
        "WHTC-Rural": 0.0,
        "WHTC-Motorway": 0.0,
        "WHTC-Engineering": 1.0,
        "ColdHotBalancingFactor": 0.0,
        "CFRegPer": 1.0,
        "FuelMap": "325kW_WHR.vmap",
        "FuelType": "EthanolPI"
      },
      {
        "WHTC-Urban": 1.0,
        "WHTC-Rural": 1.0,
        "WHTC-Motorway": 1.0,
        "WHTC-Engineering": 1.024,
        "ColdHotBalancingFactor": 1.0,
        "CFRegPer": 1.0,
        "FuelMap": "325kW_DF.vmap",
        "FuelType": "DieselCI"
      }
    ],
    "RatedPower": 0.0,
    "RatedSpeed": 0.0,
    "MaxTorque": 0.0,
    "FullLoadCurve": "325kW.vfld",
    "WHRType": [
      "ElectricalOutput"
    ],
    "WHRCorrectionFactors": {
      "Electrical": {
        "Urban": 0.0,
        "Rural": 0.0,
        "Motorway": 0.0,
        "ColdHotBalancingFactor": 0.0,
        "CFRegPer": 0.0,
        "EngineeringCorrectionFactor": 1.02
      }
    }
  }
}

Full Load and Drag Curves (.vfld)

This file contains the full load and drag curves and the PT1 values for the transient full load calculation. The file uses the VECTO CSV format.

Note: The PT1 column is not required in Declaration Mode! Pre-defined values are used.

Example:

engine speed [1/min],full load torque [Nm],motoring torque [Nm],PT1 [s]
560                 ,1180                 ,-149                ,0.6
600                 ,1282                 ,-148                ,0.6
800                 ,1791                 ,-149                ,0.6
...

Fuel Consumption Map (.vmap)

The FC map is used to interpolate the base fuel consumption before corrections are applied. For details see Fuel Consumption Calculation. The file uses the VECTO CSV format.

Extrapolation of fuel consumption map is possible in Engineering Mode (with warnings!). In Declaration Mode it is not allowed.

Example:

engine speed [rpm],torque [Nm],fuel consumption [g/h]
600               ,-45        ,0
600               ,0          ,767
600               ,100        ,1759
600               ,200        ,2890
600               ,300        ,4185
600               ,400        ,5404
600               ,500        ,6535
600               ,600        ,7578
...

Example with electric WHR*

engine speed [rpm] , torque [Nm] , fuel consumption [g/h] , whr power electric [W]
500                , -135.5      , 0                      , 200
500                , 0           , 1355                   , 200
500                , 213.4       , 3412.291               , 200
500                , 426.8       , 5830.1                 , 200
500                , 640.2       , 8316.426               , 200
500                , 853.6       , 10439.87               , 200
500                , 1067        , 12823.69               , 200
500                , 1188        , 14228.79               , 200
500                , 1401.4      , 16628.66               , 200
600                , -138        , 0                      , 200
600                , 0           , 1355                   , 200
600                , 213.4       , 3412.291               , 200
600                , 426.8       , 5830.1                 , 200
...

Electric Motor Max Torque File (.vemp)

This file contains the electric motor’s maximum drive torque and maximum recuperation torque depending on the motor’s angluar speed. The file uses the VECTO CSV format.

Example:

n [rpm] , T_drive [Nm] , T_recuperation [Nm]
0       , 802.14       , -802.14
1600    , 802.14       , -802.14
1665    , 802.14       , -802.14
1675    , 798.16       , -798.16
1685    , 793.42       , -793.42
1695    , 788.74       , -788.74
...

Electric Motor Drag Curve File (.vemd)

This file contains the electric motor’s drag torque (i.e. the eletric motor is not energized) depending on the motor’s angluar speed. The file uses the VECTO CSV format.

Example:

n [rpm] , T_drag [Nm]
0       , -10
5000    , -50

Electric Motor Map (.vemo)

This file is used to interpolate the electric power required for a certain mechanical power at the eletric motor’s shaft. The file uses the VECTO CSV format.

Example:

n [rpm], T [Nm], P_el [kW]
0      , -1600 , 19.6898
0      , -1550 , 18.5438
0      , -1500 , 17.4322
...
0      , 1450  , 16.9496
0      , 1500  , 18.0462
0      , 1550  , 19.177
0      , 1600  , 20.342
47.746 , -1600 , 11.6734
47.746 , -1550 , 10.7802
...
47.746 , -100  , -0.19622
47.746 , -50   , -0.064626
47.746 , 0     , 0.1449
...

Vehicle Boosting Limits (.vtqp)

This file contains the vehicle’s boosting limits depending on the combustion engine’s angular speed. The file uses the VECTO CSV format.

Example:

n [rpm]             , T_drive [Nm]
0                   , 1200
600                 , 0
3000                , 0

Battery Internal Voltage File (.vbatv)

This file contains the battery’s internal voltage as function of the state of charge (SoC). The file must cover the SOC range from 0 to 100%! The file uses the VECTO CSV format.

Example:

SOC , V
0   , 590
10  , 614
20  , 626
30  , 634
40  , 638
50  , 640
60  , 640
70  , 642
80  , 646
90  , 650
100 , 658

Battery Internal Resistance File (.vbatr)

This file contains the battery’s internal resistance as function of the state of charge (SoC). The file must cover the SOC range from 0 to 100%! The file uses the VECTO CSV format.

Example:

SoC , Ri
0   , 0.04
100 , 0.04
SoC , Ri-2 , Ri-10 , Ri-20
0   , 0.04 , 0.06  , 0.08
100 , 0.04 , 0.06  , 0.08

Battery Max Current Map (.vimax)

This file contains the battery’s maximum current for charging and discharging depending on the state of charge (SoC). The file must cover the SOC range from 0 to 100%! The values for both, the charging and discharging current need to be positive.

The file uses the VECTO CSV format.

Example:

SOC , I_charge , I_discharge
0   , 1620     , 1620
100 , 1620     , 1620

Gearbox File (.vgbx)

File for the definition of a gearbox in Vecto. Can be created with the Gearbox Editor.

Refers to other files:

Example:

{
  "Header": {
    "CreatedBy": "Michael Krisper (Graz University of Technology)",
    "Date": "2016-03-18T14:37:18+01:00",
    "AppVersion": "3.0.2",
    "FileVersion": 5
  },
  "Body": {
    "SavedInDeclMode": false,
    "ModelName": "Generic 8 Gears",
    "Inertia": 0.0,
    "TracInt": 1.0,
    "Gears": [
      {
        "Ratio": 3.2,
        "LossMap": "Axle.vtlm"
      },
      {
        "Ratio": 6.4,
        "LossMap": "Indirect Gear.vtlm",
        "TCactive": false,
        "ShiftPolygon": "ShiftPolygon.vgbs",
        "FullLoadCurve": "<NOFILE>"
      },
      {
        "Ratio": 4.6,
        "LossMap": "Indirect Gear.vtlm",
        "TCactive": false,
        "ShiftPolygon": "ShiftPolygon.vgbs",
        "FullLoadCurve": "<NOFILE>"
      },
      {
        "Ratio": 3.4,
        "LossMap": "Indirect Gear.vtlm",
        "TCactive": false,
        "ShiftPolygon": "ShiftPolygon.vgbs",
        "FullLoadCurve": "<NOFILE>"
      },
      {
        "Ratio": 2.6,
        "LossMap": "Indirect Gear.vtlm",
        "TCactive": false,
        "ShiftPolygon": "ShiftPolygon.vgbs",
        "FullLoadCurve": "<NOFILE>"
      },
      {
        "Ratio": 1.9,
        "LossMap": "Indirect Gear.vtlm",
        "TCactive": false,
        "ShiftPolygon": "ShiftPolygon.vgbs",
        "FullLoadCurve": "<NOFILE>"
      },
      {
        "Ratio": 1.3,
        "LossMap": "Indirect Gear.vtlm",
        "TCactive": false,
        "ShiftPolygon": "ShiftPolygon.vgbs",
        "FullLoadCurve": "<NOFILE>"
      },
      {
        "Ratio": 1,
        "LossMap": "Direct Gear.vtlm",
        "TCactive": false,
        "ShiftPolygon": "ShiftPolygon.vgbs",
        "FullLoadCurve": "<NOFILE>"
      },
      {
        "Ratio": 0.75,
        "LossMap": "Indirect Gear.vtlm",
        "TCactive": false,
        "ShiftPolygon": "ShiftPolygon.vgbs",
        "FullLoadCurve": "<NOFILE>"
      }
    ],
    "TqReserve": 20.0,
    "SkipGears": true,
    "ShiftTime": 2,
    "EaryShiftUp": true,
    "StartTqReserve": 20.0,
    "StartSpeed": 2.0,
    "StartAcc": 0.6,
    "GearboxType": "AMT",
    "TorqueConverter": {
      "Enabled": false,
      "File": "<NOFILE>",
      "RefRPM": 0.0,
      "Inertia": 0.0
    }
    "DownshiftAferUpshiftDelay": 10.0,
    "UpshiftAfterDownshiftDelay": 10.0,
    "UpshiftMinAcceleration": 0.1
  }
}

Shift Polygons Input File (.vgbs)

Defines up- and down-shift curves. See Gear Shift Model for details. The file uses the VECTO CSV format.

Example:

engine torque [Nm],downshift rpm [1/min],upshift rpm [1/min]
-400              ,560                  ,1289
759               ,560                  ,1289
1252              ,742                  ,1289
2372              ,1155                 ,1942
...

Example Graph:

A typical shift curve.

Transmission Loss Map (.vtlm)

This file defines losses in transmission components, i.e. every gear, axlegear, angledrive. See Transmission Losses for the formula how the losses are accounted in the components. The file uses the VECTO CSV format.

Input speed and input torque are meant at the engine-side.

Example:

Input Speed [rpm],Input Torque [Nm],Torque Loss [Nm]
0                ,-350             ,6.81
0                ,-150             ,5.81
0                ,50               ,5.31
0                ,250              ,6.31
0                ,450              ,7.31
0                ,650              ,8.31

Sign of torque values

  • Input Torque >0 means normal driving operation.
  • Input Torque <0 means motoring operation. The Torque Loss Map must include negative torque values for engine motoring operation!
  • Torque Loss must always be positive!

Torque Converter Characteristics (.vtcc)

The file uses the VECTO CSV format.

See Torque Converter Model for more information about the component model.

Example:

Speed Ratio, Torque Ratio, MP1000
        0.0,         1.93, 377.80
        0.1,         1.82, 365.21
        0.2,         1.70, 352.62
        0.3,         1.60, 340.02
        0.4,         1.49, 327.43
        0.5,         1.39, 314.84
        0.6,         1.28, 302.24
        0.7,         1.18, 264.46
        0.8,         1.07, 226.68
        0.9,         0.97, 188.90
        1.0,         0.97, 0.00
...

Gearshift Parameters File (.vtcu)

Empty .vtcu File - default values are used

{
  "Header": {
    "CreatedBy": " ()",
    "Date": "2016-10-13T15:52:04.0766564Z",
    "AppVersion": "3",
    "FileVersion": 1
  },
  "Body": {
     
      }
}

Example .vtcu file

{
  "Header": {
    "CreatedBy": " ()",
    "Date": "2016-10-13T15:52:04.0766564Z",
    "AppVersion": "3",
    "FileVersion": 1
  },
  "Body": {
     
    "Rating_current_gear": 0.97,
    
    "RatioEarlyUpshiftFC": 24,
    "RatioEarlyDownshiftFC": 24,    
    "VelocityDropFactor": 1.0,
    
    "ShiftTime": 0.7,
    "AccelerationFactorNP98h":0.8,
    "VelocityDropFactor": 1,
    "ATLookAheadTime": 0.8,
    
    "LoadStageThresoldsUp": "19.7;36.34;53.01;69.68;86.35",
    "LoadStageThresoldsDown": "13.7;30.34;47.01;63.68;80.35",
    "ShiftSpeedsTCLockup" : [
        [ 50, 80, 125, 50, 80, 125 ],
        [ 50, 80, 125, 50, 80, 125 ],
        [ 50, 80, 125, 50, 80, 125 ],
        [ 50, 80, 125, 70, 100, 145 ],
        [ 60, 90, 135, 80, 110, 155 ],
        [ 70, 100, 145, 90, 120, 155 ]
    ]
  }
}

Hybrid Strategy Parameters File (.vhctl)

File for the definition of the hybrid control strategy parameters in VECTO. Can be created with the Hybrid Strategy Parameters Editor.

Example:

{
  "Header": {
    "CreatedBy": "",
    "Date": "2020-09-07T15:28:08.3781385Z",
    "AppVersion": "3",
    "FileVersion": 1
  },
  "Body": {
    "EquivalenceFactor": 2.0,
    "MinSoC": 20.0,
    "MaxSoC": 80.0,
    "TargetSoC": 50.0,
    "AuxBufferTime": 5.0,
    "AuxBufferChgTime": 5.0,
    "MinICEOnTime": 10.0
  }
}

PTO Cycle (.vptoc)

The PTO cycle defines the power demands during standing still and doing a pto operation. This can only be used in Engineering Mode when a pto transmission is defined. It can be set in the Vehicle-Editor. The basic file format is Vecto-CSV and the file type ending is “.vptoc”. A PTO cycle is time-based and may have variable time steps, but it is recommended to use a resolution between 1[Hz] and 2[Hz]. Regardless of starting time, VECTO shifts it to always begin at 0[s].

Header: <t>, <Engine speed>, <PTO Torque>

Bold columns are mandatory. Only the listed columns are allowed (no other columns!).
The order is not important when the headers are annotated with <angle-brackets> (less-than-sign “<” and greater-than-sign “>”).
Units are optional and are enclosed in [square-brackets] after the header-column. Comments may be written with a preceding hash-sign “#”.

Identifier Unit Description
t [s] The time during the pto cycle. Must always be increasing. Gets shifted to begin with 0 by VECTO (if thats not already the case).
Engine speed [rpm] Actual engine speed
PTO Torque [Nm] The torque at the PTO consumer (including prop-shaft losses if applicable) as measured by the DIN test converted to torque at engine speed

Example:

<t> [s], <Engine speed> [rpm], <PTO Torque> [Nm]
0      , 600                 , 0
1      , 600                 , 0
2      , 900                 , 0
3      , 1200                , 50
4      , 1200                , 70
5      , 1200                , 100

PTO Idle Consumption Map (.vptoi)

The pto idle consumption map defines the speed-dependent power demand when the pto cycle is not active. This is only be used in Engineering Mode when a pto transmission is defined. The exact demand is interpolated based on the engine speed. PTO consumer idling losses are added to engine loads during any parts of the vehicle operation except the “PTO cycle”. It can be defined in the Vehicle-File and set via the Vehicle-Editor. The basic file format is Vecto-CSV and the file type ending is “.vptoi”.

Header: <Engine speed>, <PTO Torque>

Bold columns are mandatory. Only the listed columns are allowed (no other columns!).
The order is not important when the headers are annotated with <angle-brackets> (less-than-sign “<” and greater-than-sign “>”).
Units are optional and are enclosed in [square-brackets] after the header-column. Comments may be written with a preceding hash-sign “#”.

Identifier Unit Description
Engine speed [rpm] The engine speed.
PTO Torque [Nm] Torque Loss by the PTO consumer (including prop-shaft losses if applicable) as measured by the DIN test converted to torque at engine speed

Example:

<Engine speed> [rpm], <PTO Torque> [Nm]
600                   ,  8.0027
800                   , 12.2902
1000                  , 16.7431
1200                  , 20.3244
1400                  , 26.4444
1600                  , 32.1234

PTO power demand during drive (.vptor)

Example:

t  , PTO_Power
0  , 20
10 , 20
12 , 25
15 , 40
25 , 20
28 , 5
30 , 0

Bus Auxiliary Input Data (.aaux)

Only applicable in Engineering Mode.

Example:

{
  "Header": {
    "CreatedBy": " ()",
    "Date": "2016-10-13T10:28:40.9616564Z",
    "AppVersion": "3",
    "FileVersion": 1
  },
  "Body": {
    "PneumaticSystem": {
    "CompressorMap": "DEFAULT_3-Cylinder_2-Stage_598ccm.acmp",
    "AverageAirDemand": 0.7663,
    "SmartAirCompression": true,
    "GearRatio": 1
    },
    "ElectricSystem": {
      "AlternatorEfficiency": 0.7,
      "CurrentDemand": 54.181,
      "CurrentDemandEngineOffDriving": 54.181,
      "CurrentDemandEngineOffStandstill": 54.181,
      "ElectricStorageCapacity": 50,
      "MaxAlternatorPower": 35000,
      "AlternatorType": "smart",
      "ESSupplyFromHEVREESS": false,
      "DCDCConverterEfficiency": 1.0
    },
    "HVAC": {
    "ElectricPowerDemand": 469.76,
    "MechanicalPowerDemand": 181.28,
    "AuxHeaterPower": 5000,
    "AverageHeatingDemand": 0
  }
  }
}

Advanced Compressor Map (.acmp)

This file is used to configure the compressor map for pneumatic auxiliaries, and contains data relating to the compressor performance at various engine speeds.

File Format

The file uses the VECTO CSV format, with an example provided below.

Format

Example Configuration for Advanced Compressor Map:

RPM  , FlowRate [l/min] , Power [on] [W] , Power [off] [W]
1500 , 200              , 2000           , 1000
2000 , 400              , 4000           , 2000
3000 , 600              , 6000           , 3000
4000 , 800              , 8000           , 4000
5000 , 1000             , 10000          , 5000
6000 , 1200             , 12000          , 6000
7000 , 1400             , 14000          , 7000

The following four Default maps have been provided for use until a certified test procedure is established:

  1. DEFAULT_1-Cylinder_1-Stage_393ccm
rpm  , flowRate [l/min] , power [on] [W] , power [off] [W]
500  , 83.42357042      , 1428           , 181.9
750  , 141.6565216      , 1890           , 342.4
1000 , 198.5612781      , 2467.5         , 513.6
1250 , 241.9965577      , 3097.5         , 716.9
1500 , 293.5664883      , 3759           , 866.7
1750 , 335.5358341      , 4294.5         , 1080.7
2000 , 398.488427       , 5166           , 1273.3
2250 , 425.0944822      , 6006           , 1433.8
2500 , 458.3225806      , 6541.5         , 1540.8
2750 , 478.2312925      , 7066.5         , 1712
3000 , 511.85438        , 7665           , 1958.1
  1. DEFAULT_2-Cylinder_1-Stage_650ccm
rpm  , flowRate [l/min] , power [on] [W] , power [off] [W]
800  , 250.5365596      , 3139.5         , 524.3
1200 , 374.3533986      , 4609.5         , 1027.2
1600 , 508.4123859      , 6205.5         , 1572.9
2000 , 619.1263282      , 7770           , 2065.1
2400 , 762.6185788      , 9723           , 2696.4
2550 , 819.2371476      , 10363.5        , 2856.9
2800 , 898.7501978      , 11613          , 3349.1
3200 , 979.4827586      , 13282.5        , 4012.5
  1. DEFAULT_2-Cylinder_2-Stage_398ccm
rpm  , flowRate [l/min] , power [on] [W] , power [off] [W]
800  , 209.7130243      , 2079           , 160.5
1200 , 348.3681702      , 3160.5         , 342.4
1600 , 411.2603567      , 4315.5         , 604.55
2000 , 520.8333333      , 5901           , 963
2400 , 598.4042553      , 6961.5         , 1433.8
2550 , 618.1318681      , 7360.5         , 1637.1
2800 , 655.1473124      , 8127           , 1968.8
3200 , 806.2234795      , 10043.25       , 2755.25
3600 , 857.9169175      , 11571          , 3702.2
  1. DEFAULT_3-Cylinder_2-Stage_598ccm
rpm  , flowRate [l/min] , power [on] [W] , power [off] [W]
700  , 268.8679245      , 2698.5         , 149.8
1200 , 455.170778       , 4641           , 363.8
1700 , 619.9877948      , 6772.5         , 823.9
2200 , 723.0141287      , 8778           , 1508.7
2550 , 800.5469547      , 10468.5        , 2075.8
2800 , 913.4228898      , 12253.5        , 2461
3300 , 996.5379955      , 14070          , 3145.8
3550 , 1048.442907      , 15078          , 3755.7

Driving Cycles (.vdri)

A Driving Cycle defines the parameters of a simulated route in Vecto. It is either time-based or distance-based and has different fields depending on the driving cycle type. The basic file format is Vecto-CSV and the file type ending is “.vdri”. A Job must have at least one driving cycle (except in Declaration mode, where the driving cycles are predefined).

Driving Cycle Types

Declaration Mode Cycles

In Declaration Mode driving cycles are automatically chosen depending on vehicle category and cannot be changed by the user. These predefined cycles are of type target-speed, distance-based.

  • Construction: 100km
  • Long Haul: 100km
  • Municipal Utility: 11.25km
  • Regional Delivery: 100km
  • Urban Delivery: 100km

Verification Test Cycle

This kind of cycle is used for simulating vehicles defined in declaration mode (xml) on a real driving cycle.

Header: t, v, n_eng,n_fan, tq_left, tq_right, n_wh_left, n_wh_right, fc_, gear

Bold columns are mandatory. Italic columns are optional. Only the listed columns are allowed (no other columns!).
Units are optional and are enclosed in [square-brackets] after the header-column. Comments may be written with a preceding hash-sign “#”.

Identifier Unit Description
t [s] The absolute time. Must always be increasing.
v [km/h] The actual velocity of the vehicle. Must be >= 0 km/h.
n_eng [rpm] The actual engine speed. Must be >= 0 rpm.
n_fan [rpm] The actual engine-fan speed. Must be >= 0 rpm.
tq_left [Nm] The actual torque at the driven wheel (left side)
tq_right [Nm] The actual torque at the driven wheel (left side)
n_wh_left [rpm] The actual wheel speed of the driven wheel (left side). Must be >= 0 rpm.
n_wh_right [rpm] The actual wheel speed of the driven wheel (right side). Must be >= 0 rpm.
fc_ [g/h] Fuel consumption, this column has to be provided for every fuel in case of dual-fuel vehicles
gear [-] The actual gear

Example:

t [s]              , v [km/h]    , n_eng [rpm] , n_fan [rpm] , tq_left [Nm] , tq_right [Nm] , n_wh_left [rpm] , n_wh_right [rpm] , fc_Diesel CI [g/h] , gear
0                  , 0           , 599.7       , 727.3       , 319.1        , 429.8         , 0.78            , 0.78             , 836                , 3
0.5                , 0           , 600.2       , 727.3       , 316.7        , 430.0         , 0.78            , 0.78             , 836                , 3
1                  , 0           , 600.1       , 726.9       , 319.9        , 430.8         , 0.78            , 0.78             , 836                , 3
1.5                , 0           , 599.9       , 726.6       , 317.4        , 431.1         , 0.78            , 0.79             , 836                , 3
2                  , 0           , 600.1       , 726.2       , 319.5        , 421.7         , 0.78            , 0.78             , 836                , 3
2.5                , 0           , 599.7       , 726         , 319.0        , 434.1         , 0.78            , 0.78             , 836                , 3
3                  , 0           , 600.2       , 725.4       , 322.2        , 428.5         , 0.78            , 0.78             , 836                , 3
3.5                , 0           , 599.9       , 724.7       , 317.3        , 430.4         , 0.78            , 0.78             , 836                , 3
4                  , 0           , 599.5       , 724.0       , 320.9        , 428.0         , 0.78            , 0.78             , 836                , 3
4.5                , 0           , 599.9       , 723.4       , 187.0        , 247.6         , 0.78            , 0.78             , 836                , 3
5                  , 0           , 598.7       , 722.5       , 156.9        , 171.5         , 0.78            , 0.78             , 1003.2             , 3

Engineering Mode: Target-Speed, Distance-Based Cycle

This driving cycle defines the target speed over distance. Vecto tries to achieve and maintain this target speed.

Header: s, v, stop[, Padd][, grad][, PTO][, vair_res, vair_beta]

Bold columns are mandatory. Italic columns are optional. Only the listed columns are allowed (no other columns!).
Units are optional and are enclosed in [square-brackets] after the header-column. Comments may be written with a preceding hash-sign “#”.

Note: if the cycle starts with a target speed of 0 km/h and the stop-time for the first entry is 0, VECTO sets the stop-time to 1s automatically.

Identifier Unit Description
s [m] Traveled distance. Must always be increasing.
v [km/h] The target vehicle velocity. Must be >= 0 km/h.
stop [s] Stopping Time. Defines the time span the vehicle is standing still (time the vehicle spending in a stop phase). After this time, the vehicle tries to accelerate to v. If during a stop phase the PTO cycle is activated, it is recommended to use at least 2 seconds of stop time (which gets split up: first half before the PTO cycle, second half after the PTO cycle).
Padd [kW] Additional auxiliary power demand. This power demand will be directly added to the engine power in addition to possible other auxiliaries. Must be >= 0 kW.
grad [%] The road gradient.
HW [0/1] Marks highway sections (1) of the driving cycle. Predictive cruise control is only enabled on highway parts of the cycle
PTO [0/1/2/3] “0”=disabled, “1”=PTO active during standstill, “2”=PTO active during driving with PTO power from driving cycle, “3”=PTO active during driving, separate time-based PTO cycle. If at a vehicle stop (defined by target velocity=0) “1” is specified, the PTO cycle as specified in the *.vptoc–File is simulated. This is described in the PTO Simulation Model The PTO activation is added to the simulation time in the middle of the stopping time as defined by the cycle parameter “stop”. The PTO Cycle can be specified in the Vehicle Editor. When PTO is activated it is recommended to use at least 2 seconds as stop time.
vair_res [km/h] Air speed relative to vehicle for cross wind correction. Only required if Cross Wind Correction is set to Vair & Beta Input.
vair_beta [°] Wind Yaw Angle for cross wind correction. Only required if Cross Wind Correction is set to Vair & Beta Input.
P_PTO [kW] Auxiliary power applied for PTO activation mode 2 (PTO active during drive, PTO demand defined in cycle)

Example:

s [m]              , v [km/h]    , stop [s]    , grad [%]    , Padd [kW] |
0                  , 10          , 10          , 2.95        , 1.5
1                  , 20          , 0           , 2.97        , 1.3
2                  , 35          , 0           , 3.03        , 1.3
3                  , 50          , 0           , 2.99        , 1.3

Engineering Mode: Measured-Speed, Time-Based Cycle

This driving cycle defines the actual measured speed over time. Vecto tries to simulate the vehicle model using this speed as the actual vehicle speed. Due to differences in the real and simulated shift strategies a small difference in speed can occur, but Vecto immediately tries to catch up after the gear is engaged again.

Header: t, v[, grad][, Padd][, vair_res, vair_beta]

Bold columns are mandatory. Italic columns are optional. Only the listed columns are allowed (no other columns!).
Units are optional and are enclosed in [square-brackets] after the header-column. Comments may be written with a preceding hash-sign “#”.

Identifier Unit Description
t [s] The absolute time. Must always be increasing.
v [km/h] The actual velocity of the vehicle. Must be >= 0 km/h.
Padd [kW] Additional auxiliary power demand. This power demand will be directly added to the engine power in addition to possible other auxiliaries. Must be >= 0 kW.
grad [%] The road gradient.
vair_res [km/h] Air speed relative to vehicle for cross wind correction. Only required if Cross Wind Correction is set to Vair & Beta Input.
vair_beta [°] Wind Yaw Angle for cross wind correction. Only required if Cross Wind Correction is set to Vair & Beta Input.

Example:

t [s]     v [km/h] , grad [%]    , Padd [kW]
0            0     , 2.95        , 1.5
1          0.6     , 2.97        , 1.3
2          1.2     , 3.03        , 1.3
3          2.4     , 2.99        , 1.3

Engineering Mode: Measured-Speed With Gear, Time-Based Cycle

This driving cycle defines the actual measured speed of the vehicle, the gear, and the engine speed over time. It overrides the shift strategy of Vecto and also directly sets the engine speed.

Header: t, v, gear[, tc_active, grad][, Padd][, vair_res, vair_beta][, Aux_ID]

Bold columns are mandatory. Italic columns are optional. Only the listed columns are allowed (no other columns!).
Units are optional and are enclosed in [square-brackets] after the header-column. Comments may be written with a preceding hash-sign “#”.

Identifier Unit Description
t [s] The absolute time. Must always be increasing.
v [km/h] The actual velocity of the vehicle. Must be >= 0 km/h.
gear [-] The current gear. Must be >= 0 (0 is neutral).
tc_active [-] For AT gearboxes mandatory! Indicate if the torque converter is active or locked. Depending on the gearbox type only allowed for 1st gear or 1st and 2nd gear.
Padd [kW] Additional auxiliary power demand. This power demand will be directly added to the engine power in addition to possible other auxiliaries. Must be >= 0 kW.
grad [%] The road gradient.
vair_res [km/h] Air speed relative to vehicle for cross wind correction. Only required if Cross Wind Correction is set to Vair & Beta Input.
vair_beta [°] Wind Yaw Angle for cross wind correction. Only required if Cross Wind Correction is set to Vair & Beta Input.

Example:

t [s]              , v [km/h]    , gear [-]    , grad [%]    , Padd [kW]
0                  , 0           , 0           , 2.95        , 1.5
1                  , 0.6         , 3           , 2.97        , 1.3
2                  , 1.2         , 3           , 3.03        , 1.3
3                  , 2.4         , 3           , 2.99        , 1.3

Engineering Mode: Pwheel (SiCo), Time-Based

This driving cycle defines the power measured at the wheels over time. Vecto tries to simulate the vehicle with this power requirement.

Header: t, Pwheel, gear, n[, Padd]

Bold columns are mandatory. Italic columns are optional. Only the listed columns are allowed (no other columns!).
Units are optional and are enclosed in [square-brackets] after the header-column. Comments may be written with a preceding hash-sign “#”.

Identifier Unit Quantity Description
t [s] The absolute time. Must always be increasing.
Pwheel [kW] Power at the wheels.
gear [-] The current gear. Must be >= 0 (0 is neutral).
n [rpm] The actual engine speed. Must be >= 0 rpm.
Padd [kW] Additional auxiliary power demand. This power demand will be directly added to the engine power. Must be >= 0 kW.

Example:

t [s]              , Pwheel [kW] , gear [-]    , n [rpm]     , Padd [kW]
0                  , 0           , 0           , 600         , 1.5
1                  , 4.003       , 3           , 950         , 1.3
2                  , 15.333      , 3           , 1200        , 1.3
3                  , 50.56       , 3           , 1400        , 1.3

Engine Only Mode: Engine Only Driving Cycle

This driving cycle directly defines the engine’s power or torque at the output shaft over time. Vecto adds the engine’s inertia to the given power demand and simulates the engine.

Header: t, n, (Pe|Me)[, Padd]

Bold columns are mandatory. Italic columns are optional. Only the listed columns are allowed (no other columns!).
Units are optional and are enclosed in [square-brackets] after the header-column. Comments may be written with a preceding hash-sign “#”.

Identifier Unit Description
t [s] The absolute time. Must always be increasing.
n [rpm] The actual engine speed. Must be >= 0 rpm.
Pe [kW] The power at the output shaft of the engine. Either Pe or Me must be defined.
Me [Nm] The torque at the output shaft of the engine. Either Pe or Me must be defined.
Padd [kW] Additional auxiliary power demand. This power demand will be directly added to the engine power. Must be >= 0 kW.

Example:

t [s]              , n [rpm]     , Pe [kW]     , Padd [kW]
0                  , 600         , 0           , 1.5
1                  , 950         , 25.3        , 1.3
2                  , 1200        , 65.344      , 1.3
3                  , 1400        , 110.1       , 1.3

Acceleration Limiting Input File (.vacc)

The file is used for Acceleration Limiting. It defines the acceleration and deceleration limits as function of vehicle speed. The filepath has to be defined in the Job File. The file uses the VECTO CSV format.

Note: The deceleration should be lower than a certain threshold for low speeds in order to guarantee accurate vehicle stops during simulation. The suggested deceleration should be lower than -0.5m/s^2 for vehicle speeds below 30 km/h.

Example Data:

v [km/h],acc [m/s^2],dec [m/s^2]
0       ,1          ,-1
25      ,1          ,-1
50      ,0.6        ,-1
60      ,0.5        ,-0.5
120     ,0.5        ,-0.5

Example Graph:

The graph shows the acceleration and deceleration limits depending on the current vehicle speed.

Summary Results (.vsum)

The .vsum file includes total / average results for each calculation run in one execution (ie. click of START Button). The file is located in the directory of the fist run .vecto file.

Quantities:

Note: For dual-fuel vehicles the fuel consumption columns are present for each fuel (e.g., FC-Map_Diesel CI, FC-Map_NG CI).

Name Unit Description
Job [-] Job number in the format “X-Y” (with X as filenumber, and Y as cycle number)
Input File [-] Name of the input job file (.vecto)
Cycle [-] Name of the cycle file (or cycle name in declaration mode)
Status [-] The result status of the run (Success, Aborted)
Mass [kg] Vehicle mass (Corected Actual Curb Mass Vehicle + Curb Mass Extra Trailer/Body, see Vehicle Editor)
Loading [kg] Vehicle loading (see Vehicle Editor)
Cargo Volume [m^3] Vehicle cargo volume (Declaration Mode only!)
time [s] Total simulation time
distance [km] Total traveled distance
speed [km/h] Average vehicle speed
altitudeDelta [m] Altitude difference between start and end of cycle
FC-Map<_FuelName> [g/h], [g/km] Average fuel consumption before all corrections, interpolated from Fuel Map, based on torque and engine speed. Note: The fuel name is only stated in case of dual fuel engines.
FC-NCVc<_FuelName> [g/h], [g/km] Average fuel consumption after correcting for the net calorific value (Based on FC-Map from .vmod)
FC-WHTCc<_FuelName> [g/h], [g/km] Average fuel consumption after WHTC Correction (Based on FC-NCVc from .vmod)
FC-ESS<_FuelName> [g/h], [g/km] Average fuel consumption considering the ICE is not always off during ICE-off periods in the simulation. Considers all auxiliary demands during Off-phases taking into account the ESS utility factors
FC-ESS_Corr<_FuelName> [g/h], [g/km] Average fuel consumption including fuel consumption during engine-off periods corrected for energy demand during engine-off periods not accounted (FC-ESS_Corr = FC_WHTCc + FC_ESS)
FC-BusAux_PS_Corr<_FuelName> [g/h], [g/km] Average fuel consumption corrected for the excessive/missing energy for the smart pneumatic system, also corrected for the air demand according to the correct driving time.
FC-BusAux_ES_Corr<_FuelName> [g/h], [g/km] Average fuel consumption corrected for the excessive/missing energy for the smart electric system
FC-WHR_Corr<_FuelName> [g/h], [g/km] Average fuel consumption including fuel consumption deduction due to electric power generated by an electric WHR system (FC-WHR_Corr = FC-ESS - E_WHR_el / eta_alternator * k_vehline)
FC-SoC<_FuelName> [g/h], [g/km] Average fuel consumption to correct the REESS SoC so that the SoC at the end of the cycle mathces the SoC at the beginning
FC-SoC_Corr<_FuelName> [g/h], [g/km] Average fuel consumption including the correction for the REESS SoC
FC-BusAux_AuxHeater<_FuelName> [g/h], [g/km] Average fuel consumption of the additionalheater. In case of dual-fuel vehicles the aux heater is fueled with the primary fuel
FC-BusAux_AuxHeater_Corr<_FuelName> [g/h], [g/km] Average fuel consumptioncorrected for the aux heater fuel demand
FC-Final<_FuelName> [g/h], [g/km], [l/100km], [l/100tkm], [l/100m^3km] Final average fuel consumption after ALL corrections (FC-Final = FC-ESS_Corr). Fuel consumption for calculation of CO2 value. If Loading = 0[kg] the column [l/100tkm] is left empty.
k_vehline [g/kWh] Slope of the regression line derived from all operating points P_wheel vs. FC_final_mod where P_wheel > 0 and FC_final_mod > 0
k_engline [g/kWh] Slope of the regression line used for the fuel consumption correction
CO2 [g/km], [g/tkm], [g/m^3km] Average CO2 emissions (based on FC-Final value). Output for [l/100tkm] is empty when Loading = 0[kg].
REESS Start SoC [%] State of charge of the REESS at the beginning of the simulation run
REESS End SoC [%] State of charge pf the REESS at the end of the simulation run
ΔE_REESS [kWh] Delta energy stored in the REESS between start and end of the simulation run. Calculated from P_REESS_int.
E_REESS_loss [kWh] Total losses in the REESS due to its internal resistance
E_REESS_T_chg [kWh] Total energy charged into the REESS at the terminal (includes losses at internal resistance)
E_REESS_T_dischg [kWh] Total energy discharged from the REESS at the terminal (includes losses at the internal resistance)
E_REESS_int_chg [kWh] Total energy charged into the REES (excluding losses)
E_REESS_int_dischg [kWh] Total energy discharged from the REESS (excluding losses)
P_wheel_in_pos [kW] Average positive power at the wheels
P_wheel_in [kW] Average power at the wheels
P_fcmap_pos [kW] Average positive power at engine (all non-negative values averaged over the whole cycle duration)
P_fcmap_pos [kW] Average power at engine (both, positive and negative values, averaged over the whole cycle duration)
E_fcmap_pos [kWh] Total positive work provided by the combustion engine.
E_fcmap_neg [kWh] Total energy
E_powertrain_inertia [kWh] Total work of engine, torqueconverter, and gearbox inertia
E_aux_xxx [kWh] Energy demand of auxiliary with ID xxx applied as torque demand to the engine (i.e. mechanical energy demand). See also Aux Dialog and Driving Cycle. In Declaration Mode the following auxiliaries always exists: E_aux_FAN (Fan), E_aux_PS (Pneumatic System), E_aux_STP (Steering Pump), E_aux_ES (Electrical System), E_aux_AC (Air Condition). In case of fully electrical auxiliaries for trucks the electrical power demand is converted to mechanical power using the alternator efficiency. For Buses with fully electrical auxiliaries the consumer is connected to the electrical system and thus the according column reports 0 power demand.
E_aux_sum [kWh] Total energy demand of all auxiliaries. This is the sum for all E_aux_xxx columns and the bus auxiliaires.
E_aux_el(HV) [kWh] Total energy demand of the electric auxiliaries connected directly to the REESS.
E_clutch_loss [kWh] Total energy loss in the clutch
E_tc_loss [kWh] Total torque converter energy loss
E_gbx_loss [kWh] Total transmission energy losses at gearbox (includes loss-map, inertia, and gear-shifts). E_shift_loss is already included here.
E_shift_loss [kWh] Total energy losses due to gearshifts
E_ret_loss [kWh] Total retarder energy loss
E_angle_loss [kWh] Total torque converter energy loss
E_axl_loss [kWh] Total transmission energy losses at the axlegear
E_brake [kWh] Total work dissipated in mechanical braking (sum of service brakes, retader and additional engine exhaust brakes)
E_vehicle_inertia [kWh] Total work of wheels inertia and vehicle mass
E_air [kWh] Total work of air resistance
E_roll [kWh] Total work of rolling resistance
E_grad [kWh] Total work of gradient resistance
E_aux_ESS_missing [kWh] Total work of auxiliaries missing due to ICE off during ESS events. Used for fuel consumption correction in the post-processing.
n_EM_<POS>-em_avg [rpm] Average angular speed of the electric machine
E_EM_<POS>-em_drive [kWh] Mechanical energy at the electric motor shaft applied by the electric machine at position POS to drive the vehicle
E_EM_<POS>-em_gen [kWh] Mechanical energy at the electric motor shaft recuperated by the electric machine at position POS
η_EM_<POS>-em_drive [-] Average efficiency of the electric machine when the electric machine drives the vehicle. Based on the mechanical energy at the electric motor shaft and the electric energy.
η_EM_<POS>-em_gen [-] Average efficiency of the electric machine when the electric machine generates electric energy. Based on the mechanical energy at the electric motor shaft and the electric energy.
E_EM_<POS>_drive [kWh] Mechanical energy applied at the drivetrain by the electric machine at position POS to drive the vehicle
E_EM_<POS>_gen [kWh] Mechanical energy at the drivetrain recuperated by the electric machine at position POS
η_EM_<POS>_drive [-] Average efficiency at the drivetrain of the electric machine when the electric machine drives the vehicle. Based on the mechanical energy at the drivetrain and the electric power.
η_EM_<POS>_gen [-] Average efficiency at the drivetrain of the electric machine when the electric machine generates electric energy. Based on the mechanical energy at the drivetrain and the electric power
E_EM_<POS>_off_loss [kWh] Total losses added by the electric machine when the electric machine is not energized (i.e., the electric machine’s drag losses)
E_EM_<POS>_transm_loss [kWh] Losses of the transmission stage in the electric motor component.
E_EM_<POS>-em_loss [kWh] Total losses of the electric motor component. Calculated from P_-em_loss
E_EM_<POS>_loss [kWh] Losses of the electric machine. Calculated from P__loss
EM <POS> off time share [%] Time share the electric motor is not energized during the cycle.
BusAux PS air consumed [Nl] Total air consumed by the pneumatic system.
BusAux PS air generated [Nl] Total air generated by the pneumatic compressor. Difference to “BusAux PS air consumed” is corrected in the post-processing
E_PS_compressorOff [kWh] Total energy demand for the pneumatic compressor if no air would be generated (compressor always in drag)
E_PS_compressorOn [kWh] Total mechanical work for the pneumatic compressor to generate “BusAux PS air generated”
E_BusAux_ES_consumed [kWh] Total electric energy for all electric consumers
E_BusAux_ES_generated [kWh] Total electric energy generated
ΔE_BusAux_Bat [kWh] In case of smart electrics, the difference of energy stored in the RESS between the beginning and end of the driving cycle. This energy difference is corrected in the post-processing
E_BusAux_PS_corr [kWh] Mechanical energy of the pneumatic system that needs to be considered in the post-processing to correct the total fuel consumption
E_BusAux_ES_mech_corr [kWh] Mechanical energy of the electric system that needs to be considered in the post-processing to correct the total fuel consumption
E_BusAux_HVAC_mech [kWh] Mechancial energy demand of the HVAC system
E_BusAux_HVAC_el [kWh] Electrical energy demand of the HVAC system
E_BusAux_AuxhHeater [kWh] Energy demand of an additional aux heater.
E_WHR_el [kWh] Energy from the electric WHR system
E_WHR_mech [kWh] Energy from the mechanical WHR system
E_ice_start [kWh] Total work for starting the combustion engine, not considered in FC-Map and FC-AAUX. Considered in FC-ESS_Corr via fuel consumption correction (Based on P_ice_start in .vmod)
ice_starts [-] Number of times the combustion engine is started
E_PTO_CONSUM [kWh] Total energy demand of the pto consumer (if a pto consumer was used).
E_PTO_TRANSM [kWh] Total energy demand of the pto transmission (if a pto transmission was used).
E_WHR_el [kWh] Total electric energy generated by an electrical WHR system
E_WHR_mech [kWh] Total electric energy generated by an electrical WHR system
E_aux_PTO_RoadSweeping [kWh] Total energy demand of the pto acitvation in mode 2 (engineering mode only).
E_aux_PTO_DuringDrive [kWh] Total energy demand of the pto activation in mode 3 (engineering mode only.
E_aux_ess_mech [kWh] Total work of auxiliaries during engine stop and thus not considered in FC-Map and FC-AAUX. Considered in FC-ESS_Corr via fuel consumption correction (Based on P_aux_ESS_mech in .vmod)
a [m/s2] Average acceleration
a_pos [m/s2] Average acceleration in acceleration phases (a3s > 0.125 [m/s2], a3s = 3-seconds-averaged acceleration)
a_neg [m/s2] Average deceleration in deceleration phases (a3s < 0.125 [m/s2], a3s = 3-seconds-averaged acceleration)
AccelerationTimeShare [%] Time share of acceleration phases (a3s > 0.125 [m/s2], a3s = 3-seconds-averaged acceleration)
DecelerationTimeShare [%] Time share of deceleration phases (a3s < 0.125 [m/s2], a3s = 3-seconds-averaged acceleration)
CruiseTimeShare [%] Time share of cruise phases (-0.125 ≤ a3s ≤ 0.125 [m/s2])
StopTimeShare [%] Time share of stop phases (v < 0.1 [m/s])

Note: The fuel name is only added to the fuel consumption signals for vehicles with dual-fuel engines. In case single-fuel and dual-fuel vehicles are simulated in one simulation run, the fuel consumption for single-fuel vehicles is reported without the fuel name suffix while the fuel consumption of dual fuel vehicles contains the fuel name suffix!

Energy Bilance

To ensure the energy bilance of the vehicle, the following formulas are always ensured:

  • E_fcmap_pos = E_fcmap_neg + E_powertrain_inertia + E_aux_xxx E_clutch_loss + E_tc_loss + E_gbx_loss + E_ret_loss + E_angle_loss + E_axl_loss + E_brake + E_vehicle_inertia + E_air + E_roll + E_grad + E_PTO_CONSUM + E_PTO_TRANSM
  • E_fcmap_pos = P_fcmap_pos * time

Hint: E_shift_loss is not taken into account here, because it is already included in E_gbx_loss.

Application Files

VECTO uses a numbers of files to save GUI settings and file lists. All files are text-based and can be changed outside of VECTO if VECTO is not running.

Settings.json

This file is located in VECTO’s config folder. Here all parameters of the Settings Dialog are saved. The file uses the JSON format.

Job / Cycle lists

The job and cycle lists in the Main Form are saved in the joblist.txt / cyclelist.txt files of the config folder.

Both files save the full file paths separated by line breaks. Additionally it is saved whether each file’s checkbox is checked or not. “?1” after a file path means the file is checked (otherwise “?0”). However, this information can be omitted in which case the file will be loaded in checked state.

LOG.txt

The tabulator-separated log file saves all messages of the Main Form’s Message List and is located in VECTO’s program directory. The file is restarted whenever the Logfile Size Limit is reached.One backup is always stored as LOG_backup.txt.

License file

The license file license.dat is located in VECTO’s program directory. Without a valid lisence file VECTO won’t run.

It no valid license file is provided with your VECTO version please contact vecto@jrc.ec.europa.eu.

Changelog

VECTO-3.3.10

Build 2401 (2021-07-29) OFFICIAL RELEASE

Build 2373 (2021-07-01) RELEASE CANDIDATE

Handling of exempted vehicles

VECTO-3.3.9

Build 2175 (2020-12-15) OFFICIAL RELEASE

Build 2147 (2020-11-17) RELEASE CANDIDATE

VECTO-3.3.8

Build 2052 (2020-08-14) OFFICIAL RELEASE

Build 2024 (2020-07-17) RELEASE CANDIDATE

VECTO 3.3.7

Build 1964 (2020-05-18) OFFICIAL RELEASE

VECTO 3.3.6

Build 1916 (2020-03-31) OFFICIAL RELEASE

Build 1898 (2020-03-13) RELEASE CANDIDATE

VECTO 3.3.5

Build 1812 (2019-12-18) OFFICIAL RELEASE

Build 1783 (2019-11-19) RELEASE CANDIDATE

VECTO 3.3.4

Build 1716 (2019-09-13) OFFICIAL RELEASE

Build 1686 (2019-08-14) RELEASE CANDIDATE

VECTO 3.3.3

Build 1639 (2019-06-27) OFFICIAL RELEASE

Build 1609 (2019-05-29) RELEASE CANDIDATE

VECTO 3.3.2

Build 1548 (2019-03-29) OFFICIAL RELEASE

Build 1519 (2019-03-01) RELEASE CANDIDATE

Release Notes - VECTO: Vehicle Energy Calculation Tool - Version 3.3.2.1519-RC

VECTO 3.3.1

Build 1492 (2019-02-01) OFFICIAL RELEASE

Build 1463 (2019-01-03) RELEASE CANDIDATE

VECTO 3.3.0

Build 1433 (2018-12-03) OFFICIAL RELEASE

Build 1398 (2018-10-30) RELEASE CANDIDATE

Build 1250 (2018-06-04)

VECTO 3.2.1

Build 1133 (2018-02-07)

Build 1079 (2017-12-15)

Build 1054 (2017-11-20)

VECTO 3.2.0

Build 1022 (2017-10-19)

Build 1005 (2017-10-01)

Build 940 (2017-07-28)

Build 925 (2017-07-13)

VECTO 3.1.2

Build 810 (2017-03-21)

Build 796 (2017-03-07)

VECTO 3.1.1

Build 748 (2017-01-18)

Build 742 (2017-01-12)

VECTO 3.1.0

Build 683 (2016-11-14)

Build 662 (2016-10-24)

Build 652 (2016-10-14)


VECTO 3.0.4

Build 565 (2016-07-19)

Build 544 (2016-06-28)


VECTO 3.0.3

Build 537 (2016-06-21)

Build 495 (2016-05-10)


VECTO 3.0.2

Build 466 (2016-04-11)

Build 448 (2016-03-24)

Build 434 (2016-03-10)