CO₂MPAS: Vehicle simulator predicting NEDC CO₂ emissions from WLTP

official:

3.0.X: from 01-Feb-2019 to 01-Jan-2020

4.1.X: from 31-Oct-2019

release:

4.1.10

rel_date:

2019-11-07 12:00:00

home:

http://co2mpas.readthedocs.io/

repository:

https://github.com/JRCSTU/CO2MPAS-TA

pypi-repo:

https://pypi.org/project/co2mpas/

keywords:

CO₂, fuel-consumption, WLTP, NEDC, vehicle, automotive, EU, JRC, IET, STU, correlation, back-translation, policy, monitoring, M1, N1, simulator, engineering, scientific

mail box:

CO₂MPAS Team: <JRC-CO2MPAS@ec.europa.eu>

team:

DICE:

• Kostis Anagnostopoulos <kostis.anagnostopoulos@ext.ec.europa.eu>
• Vincenzo Arcidiacono <vincenzo.arcidiacono@ext.ec.europa.eu>
• Lorenzo Maineri <lorenzo.maineri@ext.ec.europa.eu>

Documentation:

• Vincenzo Arcidiacono <vincenzo.arcidiacono@ext.ec.europa.eu>
• Dimitrios Komnos <dimitrios.komnos@ext.ec.europa.eu>
• Francesca Saporiti <francesca.saporiti@ext.ec.europa.eu>
• Alessandro Tansini <alessandro.tansini@ec.europa.eu>

GUI:

• Kostis Anagnostopoulos <kostis.anagnostopoulos@ext.ec.europa.eu>
• Stefano Corsi <stefano.corsi@ext.ec.europa.eu>
• Ashenafi Makie <ashenafi.makie@ext.ec.europa.eu>

Legislation:

• Georgios Fontaras <georgios.fontaras@ec.europa.eu>
• Jelica Pavlovic <jelica.pavlovic@ec.europa.eu>

Model:

• Vincenzo Arcidiacono <vincenzo.arcidiacono@ext.ec.europa.eu>
• Georgios Fontaras <georgios.fontaras@ec.europa.eu>
• Jelica Pavlovic <jelica.pavlovic@ec.europa.eu>
• Alessandro Tansini <alessandro.tansini@ec.europa.eu>

Past contributors:

• Biagio Ciuffo <biagio.ciuffo@ec.europa.eu>
• Stefanos Tsiamakis <stsiakma@gmail.com>
• Victor Valverde <victor.valverde-morales@ec.europa.eu>

Supervision:

• Georgios Fontaras <georgios.fontaras@ec.europa.eu>
• Spyridon Konstantinidis <Spyridon.konstantinidis@ext.ec.europa.eu>

Tester:

• Dimitrios Komnos <dimitrios.komnos@ext.ec.europa.eu>
• Ashenafi Makie <ashenafi.makie@ext.ec.europa.eu>
• Iker Prado Rujas <iker.prado-rujas@ext.ec.europa.eu>

copyright:

2015-2019 European Commission (JRC)

license:

EUPL 1.1+

What is CO₂MPAS?

CO₂MPAS is backward-looking longitudinal-dynamics CO₂ and fuel-consumption simulator for light-duty M1 & N1 vehicles (cars and vans), specially crafted to estimate the CO2 emissions of vehicles undergoing NEDC testing based on the emissions produced WLTP testing during type-approval, according to the EU legislations 1152/EUR/2017 and 1153/EUR/2017 (see History section, below).

It is an open-source project (EUPL 1.1+) developed for Python-3.6+. It runs either as a console command or as a desktop GUI application, and it uses Excel-files or pure python structures (dictionary and lists) for its input & output data.

History

The European Commission has introduced the WLTP as the test procedure for the type I test of the European type-approval of Light-duty vehicles as of September 2017. Its introduction has required the adaptation of CO₂ certification and monitoring procedures set by European regulations (443/2009, 510/2011, 1152/EUR/2017 and 1153/EUR/2017). European Commission’s Joint Research Centre (JRC) has been assigned the development of this vehicle simulator to facilitate this adaptation.

The European Regulation setting the conditions for using CO₂MPAS can be found in the Comitology Register after its adoption by the Climate Change Committee which took place on June 23, 2016, and its 2nd vote for modifications, in April 27, 2017.

Installation

Two installation procedures can be followed:

• Official (for type approval)
• Ordinary (for developers and/or researchers)

Official (for type approval)

To install CO₂MPAS you have to download the installer and then execute it (see the steps shown in the video below).

After the installation, two icons will appear on your desktop: one for the GUI and one for the console.

IT Requirements

To run CO₂MPAS for Type Approval purposes (i.e CO₂MPAS official) some minimum IT requirements are mandatory:

• 64-bit Intel or AMD processor (x86_64, aka x64, aka AMD64),
• Microsoft Windows 7 SP1, or later,
• 4 GB RAM (more recommended),
• 4 GB hard disk storage for installing the software,
• Execution-rights to the installation folder (but no Admin-rights),
• (optional) Excel, to view & edit simulation’s input and output files,
• Chrome/Firefox/Safari/Edge or IExplore 10+.

Ordinary (for developers and/or researchers)

To install CO₂MPAS use (with root privileges):

$ pip install co2mpas

Or download the latest git version and use (with root privileges):

$ python setup.py install

Install extras

Some additional functionality is enabled installing the following extras:

• cli: enables the command line interface.
• sync: enables the time series synchronization tool (i.e., syncing previously named datasync).
• gui: enables the graphical user interface.
• plot: enables to plot the CO₂MPAS model and the workflow of each run.
• io: enables to read/write excel files.
• dice: enables the Type Approval mode.
• driver: enables the driver model (currently is not available).

To install co2mpas and all extras, do:

$ pip install co2mpas[all]

Quick Start

The following steps are basic commands to get familiar with CO₂MPAS procedural workflow using the command line interface:

• Run in engineering mode
• Input file
• Data synchronization
• GUI start-up

Run in engineering mode

To run CO₂MPAS in engineering mode with some sample data, you have to:

1. Generate some demo files inside the ./input folder, to get familiar with the input data (for more info check the link):

   ## Generate the demo files and open a demo file.
   $ co2mpas demo ./input
   $ start ./input/co2mpas_conventional.xlsx
   

2. Run CO₂MPAS in engineering mode and inspect the results in the ./output folder. The workflow is plotted on the browser (for more info check the link):

   ## Run co2mpas and open the output folder.
   $ co2mpas run ./input/co2mpas_conventional.xlsx -O ./output -PL
   $ start ./output
   

Input file

To create an input file with your data, you have to:

1. Generate an empty input template file (i.e., vehicle.xlsx) inside the ./input folder:

   ## Generate template file.
   $ co2mpas template ./input/vehicle.xlsx -TT input
   

2. Follow the instructions provided in the excel file to fill the required inputs:

   ## Open the input template.
   $ start ./input/vehicle.xlsx
   

Data synchronization

To synchronize the dyno and OBD data with the theoretical cycle, you have to:

1. Generate a synchronization template file wltp.xlsx:

   ## Generate template file.
   $ co2mpas syncing template ./to_sync/wltp.xlsx -CT wltp -WC class3b -GB automatic
   

   Note

   With the command above, the file contains the theoretical WLTP velocity profile for an automatic vehicle of class3b. For more info type co2mpas syncing template -h or click the link

2. Fill the dyno and obd sheets with the relative data collected in the laboratory:

   ## Open the input template.
   $ start ./to_sync/wltp.xlsx
   

3. Synchronize the data with the theoretical velocity profile:

   $ co2mpas syncing sync ./to_sync/wltp.xlsx ./sync/wltp.sync.xlsx
   

4. Copy/Paste the synchronized data (wltp.sync.xlsx) contained in the synced sheet into the relative sheet of the input template:

   ## Open the synchronized data.
   $ start ./sync/wltp.sync.xlsx
   

GUI start-up

To launch the CO₂MPAS GUI from the console, you can use the following command:

## Open the GUI of co2mpas.
$ co2wui run

Tutorials

This section explains the functionalities of CO₂MPAS GUI through some video tutorials:

• Inputs
  • Get input template
  • Synchronize time-series
  • Download demo files
• Run
  • Type approval mode
  • Engineering mode
  • Simulation plan
• Model plot

Inputs

This section shows the utilities to generate and populate the CO₂MPAS input file.

Get input template

Check the video to see how to download an empty input excel-file. The generated file contains the instructions on how to fill the required inputs. For more information use the command co2mpas template -h or check the link.

Synchronize time-series

If you have time-series not well synchronized and/or with different sampling rates, the model might fail. As an aid tool, you may use the syncing tool to “synchronize” and “re-sample” your data. To use the tool you should execute the following steps:

• Generate and download an empty input excel-file (see the video). For more information use the command co2mpas syncing template -h or check the link.

  Note

  All sheets must contain values for columns times and velocities because they are the reference signals used to synchronize the data with the theoretical velocity profile.

• Run data synchronization, see the video. For more information use the command co2mpas syncing sync -h or check the link.

Note

The synchronized signals are saved into the synced sheet.

Download demo files

CO₂MPAS contains 4 demo-files that can be used as a starting point to try out:

1. co2mpas_conventional.xlsx: conventional vehicle,
2. co2mpas_simplan.xlsx: sample simulation plan,
3. co2mpas_hybrid.xlsx: hybrid parallel vehicle,
4. co2mpas_plugin.xlsx: hybrid plugin vehicle.

Check the video to see how to download them. For more information use the command co2mpas demo -h or check the link.

Run

This section displays three ways to run CO₂MPAS. For more information use the command co2mpas run -h or check the link.

Type approval mode

The Type Approval command simulates the NEDC fuel consumption and CO2 emissions of the given vehicle. To produce the NEDC predictions, CO₂MPAS utilizes only the declaration inputs. If it finds some extra/missing inputs, a warning is raised and no results are produced. To successfully run CO₂MPAS in type approval mode, see the following steps:

1. Upload your file/s (multiple files are accepted):

2. Switch TA mode ON and click run:

3. Get the results:

Output files of the type-approval run.

• A zip folder per vehicle, named as <ip-name>.co2mpas.zip. This contains 4 files:

  • <ip-name>.co2mpas.hash.txt: Contains the correlation hash.
  • <ip-name>.co2mpas.input: Raw CO₂MPAS input file.
  • <ip-name>.co2mpas.output: CO₂MPAS results.
  • <ip-name>.co2mpas.ta: Correlation output report to be uploaded on dice server.

• A summary file, named as <timestamp>-summary.xlsx, that contains the relevant output results.

Engineering mode

This section explains how to run CO₂MPAS in engineering mode:

1. Upload excel file/s (see previous video),
2. Switch TA mode ON and click run:

Note

5 advanced options are available: use only declaration mode, hard validation, enable selector, only summary, and use custom configuration file. Flag the box to activate them.

3. Get the results (see the previous video).

Output files of engineering mode run.

• A CO₂MPAS output per file, named as <timestamp>-<file-name>.xlsx.
• A summary file like above.

Physical model configuration file

The configuration file (.yaml) is used to overwrite the default variables of the physical model.

Input file:

• download the conf.yaml template from the GUI as shown in the image below.

• modify it according to your parameters.

How to use it:

• Upload a new configuration file as shown in the picture.

• Flag the checkbox use custom configuration file under Advanced options.

• Run you input file as described in the Engineering mode section.

conf.yaml

• conf.yaml works ONLY in engineering mode.
• the file will be rewritten every time you upload a new one, and it will always be named conf.yaml

Simulation plan

The simulation plan is an input file containing some extra parameters/sheets with a scope plan. (see data naming convention). It defines the list of variations (i.e., inputs to be overwritten) that have to be applied to a base dataset (i.e., a normal input file of CO₂MPAS).

The simulation plan can save you time! It is able to calibrate the models just once and re-use them for other subsequent predictions, where only some inputs are different (e.g., times, velocities, vehicle_mass, etc.).

To run the simulation plan upload it as an input file, and run it as described in the previous section (i.e., Engineering mode).

Output files

• A CO₂MPAS output per file like above.
• A CO₂MPAS output per variation, named as <timestamp>-<variation-id>-<file-name>.xlsx.
• A summary file like above.

Note

The simulation plan cannot run in type-approval mode.

Model plot

This section shows the utility to investigate the CO₂MPAS model. For more information check CO2MPAS Model and API Reference.

CO₂MPAS Model

CO2MPAS model is plotted here below: you can explore the diagram nests by clicking on them.

The execution of CO₂MPAS model for a single vehicle is a procedure in three sequential stages:

• Calibration stage: identifies, calibrates, and selects the best physical models (see next section Model selection) from WLTP input data (i.e., input.calibration.<cycle>).
• Model selection stage: selects the best calibrated models (i.e., data.prediction.models_<cycle>) to be used in the prediction stage.
• Prediction stage: forecasts the CO₂ emissions using the user’s inputs (i.e., input.prediction.<cycle>) and the calibrated models. If some/all WLTP inputs are not provided, the function select_prediction_data chooses those required to predict CO₂ emissions from output.calibration.<cycle>.

The physical model is used in both stages: calibration (i.e., calibrate_with_<cycle>) and prediction (i.e., predict_<cycle>). The identified/calibrated parameters from WLTP data (i.e., data.prediction.models_<cycle>) can be grouped by functionality in eight macro-models:

1. A/T: gear shifting strategy for automatic transmission,
2. electrics: vehicle electric components ( i.e., alternator, service battery, drive battery, and DC/DC converter),
3. clutch-torque-converter: speed model for clutch or torque converter,
4. co2_params: extended willans lines parameters,
5. after-treatment: warm up strategy of after treatment,
6. engine-coolant-temperature: warm up and cooling models of the engine,
7. engine-speed: correlation from velocity to engine speed,
8. control: start/stop strategy or ECMS.

Model selection

The default model selection criteria (i.e., when enable_selector == False) are to use the calibrated models from WLTP-H data to predict WLTP-H and NEDC-H and from WLTP_L data to predict WLTP-L and NEDC-L (this logic is applied in type-approval mode).

On the contrary, if the selector is enabled, the function extract_calibrated_model detects/selects the best macro-model for prediction (from WLTP-H or WLTP-L). The selection is performed according to the model’s score, which is the model capability to reproduce the input data, i.e. a weighted average of all computed metrics.

In other words, the calibrated models are used to recalculate (predict) the inputs of the WLTP-H and WLTP-L cycles, while the scores are derived from various metrics comparing inputs against predictions.

Note

A success flag is defined according to upper or lower limits of scores which have been defined empirically by the JRC. If a score is outside the model fails the calibration and a warning is logged.

Hybrid electric vehicles model

Hybrid Electric Vehicles (HEVs) have more complex driveline layouts and control strategies compared to conventional vehicles. Their driveline integrates one or more electric machines for supporting propulsion and/or charging the drive battery, to regenerate braking power, using the engine at a more optimal operating point or even switching it off when appropriate. Therefore, additional components are needed for the simulation of their operation: electric machines, drive battery and DC/DC converter. The vehicle powertrain model of CO₂MPAS is developed in a way to capture and replicate the operation of as many different vehicle architectures as possible through a unique driveline virtual architecture.

Hybrid electric architectures

Three main architectures can be identified for HEVs driveline:

1. Parallel hybrids are similar to conventional vehicles as the engine produces mechanical power that is directly used for propulsion; also, engine rotational speed is a function of the rotational speed of the wheels according to the reduction/multiplication effect applied by final drive and gearbox (when present). The electrical machines are used to regenerate braking energy and optimise the load of the engine, but they cannot adjust the rotational speed of the engine when a gear is selected.
2. Serial hybrids have an additional degree of freedom for the optimisation, as both the load and the rotational speed of the engine can be selected by the controller. This is possible due to the lack of a mechanical coupling between the engine and the wheels. Therefore, a serial hybrid is always propelled by the electric machines and the engine is used to generate electrical energy that is used for propulsion or battery charging.
3. Planetary architecture is instead a driveline configuration that can accomplish, to some extent, the operation of the two architectures previously mentioned. The engine can provide mechanical power that is directly used for propulsion, but at the same time, its rotational speed can be adjusted by the controller becoming independent from wheel speed. This system normally replaces the conventional transmissions (gearboxes and CVTs) as it can adjust the reduction gear ratios to any wanted value, and it integrates two electric machines (one generating and the other one consuming electrical energy).

Electric power system

The Electric Power System (EPS) of HEVs is composed by three main components:

• Electric machines (P0, P1, P2, P2_pla, P3f, P3r, P4f, and P4r),
• Batteries (Drive and Service, i.e. high and low voltage batteries), and
• DC/DC converter

The electric machines convert electrical energy into mechanical energy when they need to propel the vehicle and mechanical energy into electrical during regenerative braking or battery charging. This electrical energy, consumed or generated, is exchanged with the drive battery. The DC/DC converter is the component in charge of allowing the energy exchange between the drive battery and the low-voltage electric system of the vehicle, to supply the electrical consumers and charge the service battery when needed.

The efficiency of the drive battery is modeled using the equivalent-circuit cell model (see image below). The drive battery is seen as a set of battery cells with equal characteristics and size, with a certain combination of cells in series and circuits in parallel. Each cell of the battery suffers of a power loss that is proportional to the cell internal resistance R0 and the current flowing through it, that is transformed to heat. The performance obtained by the battery is then calculated by considering how many cells in series and parallel are constituting the battery.

Control strategy

The control unit of an HEV runs an optimisation strategy to control the hybrid powertrain and assign the target power to each component (engine and electric machines). The adopted strategy adopted in CO₂MPAS is the Equivalent Consumption Minimisation Strategy (ECMS), which assigns an equivalent cost - in terms of fuel - to electrical energy use. The strategy evaluates the combination of engine and drive battery power that minimises the overall equivalent energy consumption.

Data naming conventions

This section describes the data naming convention used in CO₂MPAS input template to construct the data-values tree, i.e. the input of the simulation model. There are two naming conventions in the excel file:

• the sheet-name name is composed of 5 parts, all optional, but at least one of the first 4 must be present:

              base.input.precondition.WLTP-H.ts
              └┬─┘ └─┬─┘ └────┬─────┘ └─┬──┘ └┬┘
  scope────────┘     │        │         │     │
  usage──────────────┘        │         │     │
  stage───────────────────────┘         │     │
  cycle─────────────────────────────────┘     │
  sheet_type(optional)────────────────────────┘
  

• the data-name consists of 5 parts, the parameter part is mandatory, and the last 2 parts can be reversed:

                 plan.target.prediction.vehicle_mass.WLTP-H
                 └┬─┘ └─┬─┘ └────┬────┘ └────┬─────┘ └──┬─┘
  scope(optional)─┘     │        │           │          │
  usage(optional)───────┘        │           │          │
  stage(optional)────────────────┘           │          │
  parameter──────────────────────────────────┘          │
  cycle(optional)───────────────────────────────────────┘
  

Note

• The dot(.) may be replaced by space.
• The usage and stage parts may end with an s, denoting plural, and are not case-insensitive, e.g. Inputs sheet.

Description of the name-parts

The options of each name part are described in the following sections.

scope

• base [default]: input to CO₂MPAS simulation model.
• dice: input for dice (to run type approval mode).
• meta: meta data of the vehicle test.
• plan: data used to run a simulation plan and overwrite the inputs of the simulation model.

usage

• input [default]: input to calibration and/or to prediction models.
• data: intermediate data between calibration and prediction models (see :ref: model).
• output: CO₂MPAS precondition, calibration, and prediction results.
• target: reference-values (NOT USED NEITHER IN CALIBRATION NOR IN PREDICTION) to be compared with the CO₂MPAS results.

stage

• calibration [default]: calibration data.
• prediction [default, if cycle in nedc]: prediction data.

cycle

• nedc-h: NEDC High cycle data.
• nedc-l: NEDC Low cycle data.
• wltp-h: WLTP High cycle data.
• wltp-l: WLTP Low cycle data.
• nedc [default]: shortcut to set values for nedc-h & nedc-l.
• wltp [default]: shortcut to set values for wltp-h & wltp-l.
• all-h: shortcut to set values for nedc-h and wltp-h.
• all-l: shortcut to set values for nedc-l and wltp-l.
• all: shortcut to set values for nedc and wltp.

param

Any data-name (e.g. vehicle_mass) used in the physical model.

sheet_type

There are three sheet types, which are parsed according to their contained data:

• pl [parsed range is #A1:__]: table of scalar and time-depended values used into the simulation plan as a variation from the base model.
• pa [parsed range is #B2:C_]: scalar or not time-depended values (e.g. r_dynamic, gear_box_ratios, full_load_speeds).
• ts [parsed range is #A2:__]: time-depended values (e.g. times, velocities, gears). Columns without values are skipped. COLUMNS MUST HAVE THE SAME LENGTH!

Note

If it is not defined, the default value follows these rules: When scope is plan, the sheet is parsed as pl. If scope is base and cycle is missing in the sheet-name, the sheet is parsed as pa, otherwise, it is parsed as ts.

Simulation plan

Variations to the base model must be inserted in the provided additional sheets, characterized by the plan. prefix. These sheets consist of tables composed by rows, each row is a single simulation, and columns, the parameters that the user wishes to vary; the columns can contain the following special names:

• id: Identifies the variation id.
• base: It is the file path of a CO2MPAS excel input. The data are used as new base vehicle.
• run_base: If TRUE [default] the base model results are computed and stored, otherwise the data are just loaded.

FAQ

This page contains the most Frequently Asked Questions regarding CO₂MPAS model, regulation and inputs.

• General
  • Is the use of CO2MPAS correlation tool mandatory for all light-duty vehicles?
  • Where can the user download the latest version of the CO2MPAS?
  • Is CO2MPAS free and will it be in the future?
  • What is CO2MPAS physical background and which formulas are applied?
  • Where can the user find information on the status of the validation?
  • Where can the user find CO2MPAS workshop material?
• Model
  • What is the difference between Type Approval mode and engineering mode in CO2MPAS run?
  • What is the Data synchronization tool and how does it work?
  • What is the model selector?
  • Is it possible to simulate other cycles than NEDC or WLTP? How about real on-road tests?
  • Is the usage of internal / development signals allowed (if equivalence is shown)?
  • What is the start-stop (S/S) activation time? What might happen if the user declares it wrong?
  • How to insert a new drive_battery_technology for hybrid electric vehicles?
• Regulation
  • Where to find the correlation regulation?
  • Should CO2MPAS be used for each car or each family ID?
  • Is it possible to do a physical test instead of accepting CO2MPAS results?
  • What is DICE and who should use it?
  • What are the verification and deviation factors, and when do they need to be recorded?

For more questions, please visit: https://github.com/JRCSTU/CO2MPAS-TA/wiki/FAQ

General

Is the use of CO₂MPAS correlation tool mandatory for all light-duty vehicles?

No, the use of CO₂MPAS is not compulsory for hybrids and plug-in hybrids, double testing is allowed instead. For all the other technologies, the use of the correlation tool is mandatory. For more information and updates please see refer to point 3 of DG CLIMA’s note.

Where can the user download the latest version of the CO₂MPAS?

To download the CO₂MPAS latest version click here. To be notified of every CO₂MPAS release, watch our GitHub repository.

Is CO₂MPAS free and will it be in the future?

CO₂MPAS is and will be free. To maintain it under the current EUPL license, any modifications made to the program, or a copy of it, must be licensed in the same way: EUPL.

What is CO₂MPAS physical background and which formulas are applied?

CO₂MPAS is a backward-looking longitudinal-dynamics CO₂ and fuel-consumption simulator for light-duty M1 & N1 vehicles (cars and vans). To check the formulas the user can visit the functions’ description pages.

Where can the user find information on the status of the validation?

Detailed validation reports are provided together with every release of CO₂MPAS in the validation chapter of the wiki. Here the latest 3 reports:

• manual;
• automatic;
• and real cars, respectively;

Validation is performed as well by independent contractors (LAT) of DG CLIMA. Moreover, some stakeholders have conducted independent validation tests on real cars in collaboration with the JRC. The results of these tests have been included in the above-mentioned reports as “real cars”.

Where can the user find CO₂MPAS workshop material?

Workshop material is always uploaded in the presentation chapter.

Model

What is the difference between Type Approval mode and engineering mode in CO₂MPAS run?

In Type Approval mode CO₂MPAS simulates the NEDC CO₂ emission of the given vehicle fully aligned to the WLTP-NEDC correlation Regulation. If CO₂MPAS finds some extra input it will raise a warning and it will not produce any result. The same will happen in the case of missing inputs. The engineering mode provides the user with full control of the tool. By using the engineering mode, all the running flags become available to the user. Moreover, the user can provide additional inputs beyond the declaration ones and check their effect on the NEDC CO₂ prediction.

What is the Data synchronization tool and how does it work?

Synchronization of data from different sources is essential for robust results. CO₂MPAS syncing tool uses a common signal as a reference. To avoid time-aligned signals, we advise using the velocity present on the dyno and the obd at the same time. syncing tool will shift and re-sample the other signals according to the reference signal provided. The user is allowed to apply different ways of re-sampling the original signals. For more information, please see the instructions.

What is the model selector?

CO₂MPAS consists of several models. If the user provides both WLTP-H and WLTP-L data, the same models will be calibrated twice, according to the data provided by each configuration. If the option model selector is switched on, CO₂MPAS will use the model that provides the best scores, no matter if the model was calibrated with another cycle. For example, if the alternator model of the High configuration is better, the same model will be used to predict the Low configuration as well.

Is it possible to simulate other cycles than NEDC or WLTP? How about real on-road tests?

Yes, CO₂MPAS can simulate other cycles, as well as on-road tests. The user can simulate using several extra parameters beyond the official laboratory-measured ones. The user can input the velocity profile followed, road grade, extra auxiliaries losses, extra passengers, different road loads, temperatures, etc. The user will find an example file when downloading the demo files.

Is the usage of internal / development signals allowed (if equivalence is shown)?

OBD signals are regulated and the only one to be used.

What is the start-stop (S/S) activation time? What might happen if the user declares it wrong?

S/S is the time elapsed from the beginning of the NEDC test to the first time the Start-Stop system is enabled, expressed in seconds [s]. S/S is one of the variables that are subject to verification in case of random testing. If during verification test (random test) S/S activation time declared in CO₂MPAS is lower than the span between the beginning of the NEDC test and the first engine stop, that will result in Verification Factor equal to 1 and this will have implications on the entire fleet of the specific vehicle manufacturer.

How to insert a new drive_battery_technology for hybrid electric vehicles?

For TA: the parameter already contains a preselection of drive batteries technologies as a drop-down menu. If you need to insert a different technology, please contact us at jrc-co2mpas@ec.europa.eu.

For non TA: the parameter already contains a preselection of drive batteries technologies as a drop-down menu. If you need to insert a different technology, you should remove the “data validation rule” of the excel input file, insert the new data and proceed with the co2mpas run.

Regulation

Where to find the correlation regulation?

Below some useful links:

• The correlation regulation for passenger vehicles REGULATION (EU) 2017/1153,
• The correlation regulation for light commercial vehicles REGULATION (EU) 2017/1152
• Also, in this document, the reader will find some frequently asked questions regarding the correlation procedure.

Should CO₂MPAS be used for each car or each family ID?

For each interpolation family ID (IFID). Vehicle-H and Vehicle-L are utilized to define the interpolation line of Interpolation Family ID.

Is it possible to do a physical test instead of accepting CO₂MPAS results?

Yes, there are cases when CO₂MPAS results can be discarded and a physical test can be performed instead. For more details, check Annex I, 3.2.2.

What is DICE and who should use it?

DICE is the tool assigning a random number to each IFID type approved. It is used only for type approving purposes, by designated users.

What are the verification and deviation factors, and when do they need to be recorded?

These values need to be recorded when the random number is 90, or above, and the CO₂MPAS deviation is LESS than 4 percent. For more details please refer to the correlation regulation.

Glossary

this page lists and explains the terms used in the input file.

DICE

extension

Expansion of the interpolation line (i.e. extension of the CO₂ values). It cannot be performed for any other purposes (EVAP, etc.). It is defined in section 3 of Annex I of Regulation (EC) No 692/2008.

bifuel

A vehicle with multi-fuel engine, capable of running on two fuels.

incomplete

A vehicle that must undergo at least one further stage of completion before it can be considered complete.

atct_family_correction_factor

Family correction factor used to correct for representative regional temperature conditions (ATCT).

wltp_retest

It indicates which test conditions have been subject to retesting (see point 2.2a of Annex I of Regulation (EU) 2018/2043). Input can have multiple letters combination, leave it empty if not applicable.

parent_vehicle_family_id

The family identifier code of the parent.

regulation

It indicates if WLTP test has been performed in accordance with point 5.1.2 of Annex VIII to Regulation (EU) No 582/2011.

vehicle_family_id

The family identifier code shall consist of one unique string of n-characters and one unique WMI code followed by ‘1’.

input_type

It indicates the data input type, i.e. Pure ICE, NOVC-HEV, or OVC-HEV.

comments

A field to add comments regarding the DICE procedure. In case of extension, or resubmission, kindly provide a detailed description.

Model Inputs

fuel_type

It refers to the type of fuel used during the vehicle test. The user must choose the correct one among the following:

• diesel,
• gasoline,
• LPG,
• NG,
• ethanol,
• methanol,
• biodiesel, and
• propane.

engine_fuel_lower_heating_value

Lower heating value of the fuel used in the test, expressed in [kJ/kg] of fuel.

fuel_heating_value

Fuel heating value in kwh/l: Value according to Table A6.App2/1 in Regulation (EU) No [2017/1151][WLTP].

fuel_carbon_content_percentage

The amount of carbon present in the fuel by weight, expressed in [%].

ignition_type

It indicates whether the engine of the vehicle is a spark ignition (= positive ignition) or a compression ignition one.

engine_capacity

The total volume of all the cylinders of the engine expressed in cubic centimeters [cc].

engine_stroke

It is the full travel of the piston along the cylinder, in both directions. It is expressed in [mm].

idle_engine_speed_median

It represents the engine speed in warm conditions during idling, expressed in revolutions per minute [rpm]. It can be measured at the end of a WLTP test.

engine_n_cylinders

It specifies the maximum number of the engine cylinders. The default is 4.

engine_idle_fuel_consumption

It measures the fuel consumption of the vehicle in warm conditions during idling. The idling fuel consumption of the vehicle, expressed in grams of fuel per second [gFuel/sec] should be measured when:

• the velocity of the vehicle is 0,
• the start-stop system is disengaged,
• the battery state of charge is at balance conditions.

For CO₂MPAS purposes, the engine idle fuel consumption can be measured as follows: just after a WLTP physical test, when the engine is still warm, leave the vehicle to idle for 3 minutes so that it stabilizes. Then make a constant measurement of fuel consumption for 2 minutes. Disregard the first minute, then calculate idle fuel consumption as the average fuel consumption of the vehicle during the subsequent 1 minute.

final_drive_ratio

It is the ratio of gearbox output shaft to driven wheel revolutions. If the vehicle has more than one final drive ratio, it has to be left blank and use the final_drive_ratios.

final_drive_ratios

It specifies the final-drive ratios for each gear.

tyre_code

The code of the tyres used in the WLTP/NEDC test (e.g., P195/55R16 85H). CO₂MPAS does not require the full tyre code to work, however at least provide the following information (e.g., 195/55R16):

• nominal width of the tyre, in [mm];
• the ratio of height to width [%]; and
• the load index.

In case that the front and rear wheels are equipped with tyres of different radius (tyres of different width do not affect CO₂MPAS), then the size of the tyres fitted in the powered axle should be declared as input to CO₂MPAS. For vehicles with different front and rear wheels tyres tested in 4x4 mode, then the size of the tyres from the wheels where the OBD/CAN vehicle speed signal is measured should be declared as input to CO₂MPAS.

gear_box_type

The type of gearbox among automatic transmission, manual transmission, continuously variable transmission (CVT) or planetary (exclusively for hybrid vehicles fitted with a planetary gearset).

start_stop_activation_time

It is the time elapsed from the beginning of the NEDC test to the first time the Start-Stop system is enabled, expressed in seconds [s].

alternator_nominal_voltage

Alternator nominal voltage [V], i.e. the nominal voltage of the service battery.

alternator_nominal_power

Alternator maximum power [kW], i.e. the rated power of the electric machine.

service_battery_capacity

Capacity [Ah] of the service battery, e.g. the low voltage battery.

service_battery_nominal_voltage

Service battery nominal voltage [V] as described in Appendix 2 to Sub-Annex 6 to Annex XXI to Regulation (EU) No [2017/1151][WLTP].

initial_temperature

The initial temperature of the test cell during the test. It is used to calibrate the thermal model. The default value is 23 °C for WLTP and 25 °C for NEDC.

alternator_efficiency

It is the ratio of electrical power out of the alternator to the mechanical power put into it. If not expressed by the manufacturer, then it is by default 0.67.

gear_box_ratios

It defines the ratios of engine to gearbox output shaft revolutions.

full_load_speeds

They are rotational speed setpoints defining the engine full load curve expressed in RPM.

full_load_powers

They are power values defining the engine full load curve expressed in kW.

vehicle_mass

• For the WLTP: it is the simulated inertia applied during the test on the dyno [kg]. It should reflect correction for rotational mass m_r as foreseen by WLTP regulation for 1-axle chassis dyno testing. (Regulation 2017/1151; Sub-Annex 4; paragraph 2.5.3).
• For the NEDC: it is the inertia [kg] class of NEDC without the correction for rotating parts [kg].

f0

It corresponds to the rolling resistance force [N] when the angle slope is 0 applied to the Dyno during the test cycle. This is defined by Dyno procedure.

f1

It corresponds to the resistance \([\frac{N}{kmh}]\) function of the velocity applied to the Dyno during the test cycle. This is defined by Dyno procedure.

f2

It corresponds to the aerodynamic resistance \([\frac{N}{{kmh}^2}]\) applied to the Dyno during the test cycle. This is defined by Dyno procedure.

co2_emission_low

It is the CO₂ emissions bag value [g|CO2|/km] of WLTP low phase, not corrected for RCB and not rounded.

co2_emission_medium

It is the CO₂ emissions bag value [g|CO2|/km] of WLTP medium phase not corrected for RCB and not rounded.

co2_emission_high

It is the CO₂ emissions bag value [g|CO2|/km] of WLTP high phase not corrected for RCB and not rounded.

co2_emission_extra_high

It is the CO₂ emissions bag value [g|CO2|/km] of WLTP extra high phase not corrected for RCB and not rounded.

depleting_co2_emission_value

It is the combined CO₂ emissions value [g|CO2|/km] of the charge depleting tests.

fuel_consumption_value

It is the combined fuel consumption [l/100km] of the test not corrected.

sustaining_fuel_consumption_value

It is the combined fuel consumption [l/100km] of the charge sustaining test not corrected.

rcb_correction

It says if the RCB correction has to be (or has been) performed.

speed_distance_correction

It says if the speed distance correction has to be (or has been) performed.

corrected_co2_emission_value

It is the combined CO₂ emissions value [g|CO2|/km] corrected for RCB (if applicable), speed & distance (if applicable), Ki factor (if applicable), and ATCT (MCO2, C, 5 values from appendix 4 to Annex I to Regulation (EU) 2017/1151).

corrected_sustaining_co2_emission_value

It is the combined CO₂ emissions value [g|CO2|/km] of the charge sustaining test corrected for RCB (if applicable), speed & distance (if applicable), Ki factor (if applicable), and ATCT (MCO2, C, 5 values from appendix 4 to Annex I to Regulation (EU) 2017/1151).

declared_co2_emission_value

It is the declared CO₂ emissions value [g|CO2|/km]. Value should be corrected for RCB (if applicable), speed & distance (if applicable), Ki factor (if applicable), and ATCT (MCO2, C, 5 values from appendix 4 to Annex I to Regulation (EU) 2017/1151).

declared_sustaining_co2_emission_value

It is the declared CO₂ emissions value [g|CO2|/km] of the charge sustaining test. Value should be corrected for RCB (if applicable), speed & distance (if applicable), Ki factor (if applicable), and ATCT (MCO2, C, 5 values from appendix 4 to Annex I to Regulation (EU) 2017/1151).

declared_depleting_co2_emission_value

It is the declared CO₂ emissions value [g|CO2|/km] of the charge depleting tests. Value should be corrected for RCB (if applicable), speed & distance (if applicable), Ki factor (if applicable), and ATCT (MCO2, C, 5 values from appendix 4 to Annex I to Regulation (EU) 2017/1151).

transition_cycle_index

Index of the transition cycle according to entry 2.1.1.4.1.4 of Appendix 8a to Annex I to Regulation (EU) 2017/1151. The transition cycle is the cycle before the confirmation cycle (where the break-off criterion is satisfied) in the charge-depleting sequence. In the transition cycle the operation of the vehicle can be partly charge-depleting and partly charge-sustaining.

relative_electric_energy_change

The Relative Electric Energy Change (REEC) is a measure of the discharge of the vehicle traction REESS during the Charge Depleting test. It is calculated as the energy battery balance over the cycle divided by cycle energy, according to paraghraph 3.2.4.5.2 of Sub-Annex 8 to Annex XXI to Regulation (EU) 2017/1151.

wltp_electric_range

The cycle-specific equivalent all-electric range (EAER) is an indication of the distance that the vehicle can drive using electric energy, according to paraghraph 4.4.4 of Sub-Annex 8 to Annex XXI to Regulation (EU) 2017/1151.

nedc_electric_range

The NEDC electric range, calculated according to paragraph 4.2.2.1 of Annex 9 to UN Regulation 101, is an indication of the distance that the vehicle can drive using electric energy.

n_wheel_drive

It specifies whether the test is conducted on 2-wheel driving or 4-wheel driving.

engine_is_turbo

It specifies if the air intake of the engine is equipped with any kind of forced induction system set like a turbocharger or supercharger.

has_start_stop

It specifies if the start-stop system shuts down the engine of the vehicle during idling to reduce fuel consumption and it restarts it again when the footbrake/clutch is pressed.

has_energy_recuperation

It specifies if the vehicle is equipped with any kind of brake energy recuperation technology or regenerative breaking.

has_torque_converter

It specifies if the vehicle is equipped with a torque converter.

fuel_saving_at_strategy

It allows CO₂MPAS to use gear at constant speed driving higher than when in transient conditions, resulting in a reduction of the fuel consumption.

has_periodically_regenerating_systems

It specifies if the vehicle is equipped with periodically regenerating systems (anti-pollution devices such as catalytic converter or particulate trap). During cycles where regeneration occurs, emission standards need not apply. If a periodic regeneration occurs at least once per Type 1 test and has already occurred at least once during vehicle preparation or the distance between two successive periodic regenerations is more than 4000 km of driving repeated Type 1 tests, it does not require a special test procedure. In this case, Ki factor should be set to 1.0 (ki_multiplicative), or 0.0 (ki_additive).

engine_has_variable_valve_actuation

It specifies if the engine is equipped with technologies that are used to enable variable valve event timing, duration and/or lift. For example, Valve Timing Control (VTC) — also referred to as Variable Valve Timing (VVT) systems - and Variable Valve Lift (VVL) or a combination of these systems (phasing, timing and lift variation).

has_engine_idle_coasting

It specifies if the engine is allowed to idle during vehicle coasting in order to save fuel.

has_engine_off_coasting

It specifies if the engine is allowed to turn off during vehicle coasting in order to save fuel.

engine_has_cylinder_deactivation

It specifies if the engine has a cylinder deactivation system. If yes provide the active cylinder ratios in the tab active_cylinder_ratios.

active_cylinder_ratios

They are the plausible deactivation ratios. For example, in the case of an 8-cylinder engine, a 50% deactivation (4 cylinders off) or a 25% deactivation ratio (2 cylinders off) are plausible.

Note that the active_cylinder_ratios always start with 1 (all cylinders are active) and then the user can set the corresponding plausible ratios.

has_lean_burn

It specifies if the vehicle has lean-burn (LB) technology. This technology refers to the burning of fuel with an excess of air in an internal combustion engine.

has_gear_box_thermal_management

It specifies if the temperature of the gearbox is regulated from the vehicle’s cooling circuit using a heat-exchanger, heating storage system or other methods for directing engine waste-heat to the gearbox. Gearbox mounting and other passive systems (encapsulation) should not be considered.

has_exhausted_gas_recirculation

It specifies if a portion of an engine’s exhaust gas back to the engine cylinders to reduce NO_x emissions. The technology does not concern internal (in-cylinder) EGR.

has_selective_catalytic_reduction

It specifies if the vehicle has the Selective Catalytic Reduction (SCR) system active (Urea), or passive (Ammonia) to reduce NO_x emissions.

n_dyno_axes

It defines the Dyno rotating axis used during the test.

kco2_wltp_correction_factor

CO₂-emission correction coefficient (KCO2) for charge sustaining battery energy balance correction. Paragraph 2.3.2 of Appendix 2 of Sub-Annex 8 to Annex XXI to Regulation (EU) 2017/1151.

kco2_nedc_correction_factor

CO₂-emission correction coefficient (KCO2) for charge sustaining battery energy balance correction. Paragraph 5.3.5 of Annex 8 of UNECE Regulation No. 101 Rev.3.

planetary_ratio

It is the ratio existing between the planetary speed and the final drive speed during electric drive (engine speed =0). The planetary speed is the rotational speed of the planetary gearset side that is not the engine nor the final drive side (the branch that goes to the motor P2 planetary, referred to as the planetary side in this documentation).

initial_drive_battery_state_of_charge

It is the initial state of charge of the drive battery at the beginning of the test.

drive_battery_n_cells

It is the number of cells of the drive battery.

drive_battery_technology

If is the technology of the drive battery. The technologies included in CO₂MPAS are:

• NiMH: Nickel-metal hydride
• Li-NCA (Li-Ni-Co-Al): Lithium Nickel Cobalt Aluminum Oxide
• Li-NCM (Li-Ni-Mn-Co): Lithium Nickel Manganese Cobalt Oxide
• Li-MO (Li-Mn): Lithium Manganese Oxide
• Li-FP (Li-Fe-P): Lithium Iron Phosphate
• Li-TO (Li-Ti): Lithium Titanate Oxide

drive_battery_capacity

Capacity [Ah] of the drive battery, e.g. the high voltage battery.

drive_battery_nominal_voltage

Drive battery nominal voltage [V], e.g. the nominal voltage of the high voltage battery.

motor_p0_maximum_power

Maximum power (i.e., the rated power) output of motor P0 [kW].

motor_p0_maximum_torque

Maximum torque output of motor P0 [Nm].

motor_p0_speed_ratio

The ratio between motor P0 speed and engine speed [-] (e.g. motor P0 connected to the engine belt with ratio equal to 3 is spinning three times faster than the engine).

motor_p1_maximum_power

Maximum power (i.e., the rated power) output of motor P1 [kW].

motor_p1_maximum_torque

Maximum torque output of motor P1 [Nm].

motor_p1_speed_ratio

The ratio between motor P1 speed and engine speed [-] (e.g. motor P1 connected to the engine crankshaft with ratio equal to 3 is spinning three times faster than the engine).

motor_p2_maximum_power

Maximum power (i.e., the rated power) output of motor P2 [kW].

motor_p2_maximum_torque

Maximum torque output of motor P2 [Nm].

motor_p2_speed_ratio

The ratio between motor P2 speed and transmission input speed [-] (motor P2 speed is proportional to wheels rotational speed multiplied by the final drive ratio and the transmission gear ratio).

motor_p2_planetary_maximum_power

Maximum power (i.e., the rated power) output of motor P2 planetary [kW].

motor_p2_planetary_maximum_torque

Maximum torque output of motor P2 planetary [Nm].

motor_p2_planetary_speed_ratio

The ratio between planetary motor P2 speed and planetary side (branch that goes to planetary motor P2) speed.

motor_p3_front_maximum_power

Maximum power (i.e., the rated power) output of motor P3 front [kW].

motor_p3_front_maximum_torque

Maximum torque output of motor P3 front [Nm].

motor_p3_front_speed_ratio

The ratio between motor P3 front speed and final drive input speed [-] (motor P3 front speed is equal to wheels rotational speed multiplied by the final drive ratio and ), where final drive input speed is the rotational speed of the shaft downstream the gearbox (therefore it’s part of the engine driveline).

motor_p3_rear_maximum_power

Maximum power (i.e., the rated power) output of motor P3 rear [kW].

motor_p3_rear_maximum_torque

Maximum torque output of motor P3 rear [Nm].

motor_p3_rear_speed_ratio

The ratio between motor P3 rear speed and final drive input speed [-] (motor P3 rear speed is proportional to wheels rotational speed multiplied by the final drive ratio), where final drive input speed is the rotational speed of the shaft downstream the gearbox (therefore it’s part of the engine driveline).

motor_p4_front_maximum_power

Maximum power (i.e., the rated power) output of motor P4 front [kW]. When two P4 motors are present on the same axle, their specifications have to be combined to obtain an equivalent single motor in P4 position.

motor_p4_front_maximum_torque

Maximum torque output of motor P4 front [Nm]. When two P4 motors are present on the same axle, their specifications have to be combined to obtain an equivalent single motor in P4 position.

motor_p4_front_speed_ratio

The ratio between motor P4 front speed and wheels speed [-] (motor P4 front speed is proportional to wheels rotational speed).

motor_p4_rear_maximum_power

Maximum power (i.e., the rated power) output of motor P4 rear [kW]. When two P4 motors are present on the same axle, their specifications have to be combined to obtain an equivalent single motor in P4 position.

motor_p4_rear_maximum_torque

Maximum torque output of motor P4 rear [Nm]. When two P4 motors are present on the same axle, their specifications have to be combined to obtain an equivalent single motor in P4 position.

motor_p4_rear_speed_ratio

The ratio between motor P4 rear speed and wheels speed [-] (motor P4 rear speed is proportional to wheels rotational speed).

Time Series

times

It is the time vector [s].

velocities

It is the actual vehicle speed vector [km/h] from the dynamometer.

obd_velocities

It is the actual vehicle speed vector [km/h] from the OBD.

gears

It is the actual gear vector [-]. If the name of the parameter is target.calibration.gears it refers to the theoretical gears calculated according to Heinz Steven tool [-].

bag_phases

It is the array to associate time values with different bag phases (this can be used to modify the duration of the phases from the default values).

engine_speeds_out

It is the actual engine rotational speed vector [rpm] from the OBD.

engine_coolant_temperatures

It is the actual engine coolant temperature vector [°C] from the OBD.

co2_normalization_references

It is the normalization reference for CO₂ emissions (e.g. engine load, engine power output).

alternator_currents

It is the current vector produced by the alternator [A] (current is negative when the alternator is supplying power to the low-voltage electrical system).

service_battery_currents

It is the current vector flowing through the service battery [A] (current is positive when the battery is being charged, negative when discharged).

drive_battery_voltages

It is the voltage vector of the drive battery [V].

drive_battery_currents

It is the current flowing through the drive battery [A] (current is positive when the battery is being charged, negative when discharged).

dcdc_converter_currents

It is the current flowing through the DCDC converter measured on the low-voltage side [A] (current is negative when the DCDC converter is supplying power to the low-voltage electrical system).

General Terms

type-approval

It is the authority that grants that a vehicle conforms to the EU Regulation.

EU legislation

COMMISSION IMPLEMENTING REGULATION (EU) 2017/1152: sets out a methodology for determining the correlation parameters necessary for reflecting the change in the regulatory test procedure with regard to light commercial vehicles. COMMISSION IMPLEMENTING REGULATION (EU) 2017/1153: sets out a methodology for determining the correlation parameters necessary for reflecting the change in the regulatory test procedure and amending Regulation (EU) No 1014/2010.

Contributing to co2mpas

If you want to contribute to CO₂MPAS and improve it, your help is very welcome. Your contribution should be sent by a pull request. Next sections explains how to implement and submit a new functionality:

• clone the repository
• implement a new functionality
• open a pull request

Clone the repository

The first step to contribute to CO₂MPAS is to clone the repository:

• Create a personal fork of the co2mpas repository on Github.
• Clone the fork on your local machine. Your remote repo on Github is called origin.
• Add the original repository as a remote called upstream, to maintain updated your fork.
• If you created your fork a while ago be sure to pull upstream changes into your local repository.
• Create a new branch to work on! Branch from dev.

How to implement a new functionality

Test cases are very important. This library uses a data-driven testing approach. To implement a new function I recommend the test-driven development cycle. Hence, when you think that the code is ready, add new test in test folder.

When all test cases are ok (python setup.py test), open a pull request.

Note

A pull request without new test case will not be taken into consideration.

How to open a pull request

Well done! Your contribution is ready to be submitted:

• Squash your commits into a single commit with git’s interactive rebase. Create a new branch if necessary. Always write your commit messages in the present tense. Your commit message should describe what the commit, when applied, does to the code – not what you did to the code.
• Push your branch to your fork on Github (i.e., git push origin dev).
• From your fork open a pull request in the correct branch. Target the project’s dev branch!
• Once the pull request is approved and merged you can pull the changes from upstream to your local repo and delete your extra branch(es).

API Reference

The core of the library is composed from the following modules:

Defines the file processing chain model dsp.

core	Functions and dsp model to processes a CO2MPAS input file.
cli	Define CO2MPAS command line interface.
utils	It contains classes and functions of general utility.
defaults	Constants for the CO2MPAS physical model.

Changelog

v4.1.10 (2019-11-07)

Fix

• (optimization) #561: Use float32 for fmin error function.

v4.1.9 (2019-11-04)

Fix

• (excel): Correct parser for all-l.
• (schema): Correct error message for input file version.
• (template): Correct wrong cell reference.
• (setup): Fixed link setup.

v4.1.8 (2019-10-24): Wine Release

CO₂MPAS project has been split into multiple repositories (#506). The current repository contains just CO₂MPAS model. The other functionalities are installed as extra (i.e., DICE, GUI, sync).

Important changes:

The main changes made in this release regards:

GUI

A new graphical user interface (GUI) has replaced the previous one.

Documentation

All documentation has been reviewed and updated (#533, #540). There are two new sections: FAQ, and Contributing to CO₂MPAS. The documentation is now stored in Read the Docs (see the site).

I/O Data & Demo

The input excel file has been updated to version 3.1.0. (#544), as per the 2019 amendments to Regulations (EU) 2017/1152 and 2017/1153.

The demo files have been reviewed and now four files are available (#544, #538):

1. co2mpas_conventional.xlsx: conventional vehicle,
2. co2mpas_simplan.xlsx: sample simulation plan,
3. co2mpas_hybrid.xlsx: hybrid parallel vehicle.
4. co2mpas_plugin.xlsx: hybrid plugin vehicle.

Model

• Implemented Hybrids Electric Model for parallel, planetary, and serial architectures (#516, #536, #540, #541). It consists of nine electric motors (i.e., P0, P1, P2 planetary, P2, P3 front, P3 rear, P4 front, P4 rear, and starter), one DC/DC converter, and two batteries (i.e., service and drive batteries).
• Improved the stability of the thermal model (#458, #498, #516), the gearbox identification (#551) and the alternator model.
• Corrected the calibration of the Start/Stop model (#512).
• Updated the torque converter model according to VDI253 standard (#515).
• Refined the cylinder deactivation model (#517).
• Implemented parser for PAX tyre code (#507).
• Added formulas to calculate the corrected CO₂ emissions according to WLTP and NEDC regulations (#539).

Known Limitations

1. Certain programs (for example Skype) could be pre-empting (or reserving) some tcp/ip ports and therefore could conflict with CO₂MPAS graphical interface that tries to launch a web server on a port in the higher range (> 10000).

2. Certain antivirus (for example Avast) could include python in the list of malicious software; however, this is not to be considered harmful. If this happens the antivirus should be disabled when running CO₂MPAS, or a special exclusion should be granted to the CO₂MPAS executable.

3. If CO₂MPAS is installed in Windows 7 without ServicePack-1, you will get an error like the following:

   Error loading Python DLL 'C:\Users\admin\AppData\Local\Temp\_MEI60402\python36.dll'.
   LoadLibrary: The specified procedure could not be found.
   Error loading Python DLL 'C:\Users\admin\AppData\Local\Temp\_MEI59722\python36.dll'.
   LoadLibrary: The specified procedure could not be found.
   Delete file: C:\apps\co2mpas\pkgs\env.txt
   Output folder: C:\apps\co2mpas\conda-meta
   Extract: history
   Creating CO2MPAS menus...
   Error loading Python DLL 'C:\Users\admin\AppData\Local\Temp\_MEI51722\python36.dll'.
   LoadLibrary: The specified procedure could not be found.
   Execute: "C:\apps\co2mpas\pythonw.exe" -E -s "C:\apps\co2mpas\Lib\_nsis.py" mkdirs
   Running post install...
   Execute: "C:\apps\co2mpas\pythonw.exe" -E -s "C:\apps\co2mpas\Lib\_nsis.py" post_install
   Created uninstaller: C:\apps\co2mpas\Uninstall-CO2MPAS.exe
   Completed
   

4. If you use Internet Explorer version 9 or earlier, you might experience some problems (i.e., impossible to choose the input file for the synchronisation, etc..).

v3.0.0 (2019-01-29): “VOLO” Release

CO₂MPAS 3.0.X becomes official on February 1st, 2019.

• There will be an overlapping period with the previous official CO₂MPAS version 2.0.0 of 2 weeks (until February 15th).
• This release incorporates the amendments of the Regulation (EU) 2017/1153, 2018/2043 of 18 December 2018 to the Type Approval procedure along with few fixes on the software.
• The engineering-model is 100% the same with the 2.1.0, 30-Nov-2018: “DADO” Release and the version-bump (2.X.X –> 3.X.X) is just facilitation for the users, to recognize which release is suitable for the amended Correlation Regulations.
• The Type Approval mode (_TA_) of this release is incompatible with all previous Input File versions. The _Batch_ mode, for engineering purposes, remains compatible.
• the _TA_ mode of this release generates a single “_.zip_” output that contains all files used and generated by CO₂MPAS.
• This release is comprised of 4 python packages: co2sim, co2dice, co2gui, and co2mpas.

Installation

This release will not be distributed as an AllInOne (AIO) package. It is based on the 2.0.0, 31-Aug-2018: “Unleash” Release, launched on 1 September 2018. There are two options for installation:

1. Install it in your current working AIO-v2.0.0.
2. Preferably in a clean AIO-v2.0.0, to have the possibility to use the old CO₂MPAS-v2.0.0 + DICE2 for the two-week overlapping period;

• To install:

  `console pip uninstall co2sim co2dice co2gui co2mpas -y pip install co2mpas `

Note

If you want to install this specific version at a later date, after more releases have happened, use this command: `console pip install co2mpas==3.0.0 `

Important Changes

Model

No model changes.

IO Data

• Input-file version from 3.0.0 –> 3.0.1. - It hosts a few modifications after interactions with users. - The input file contained in this release cannot run in older CO₂MPAS releases in the _TA_ mode.

DICE

• The old DICE2 is deprecated, and must not be used after the 15th of February,
• it is replaced by the centralized DICE3 server. There will be a new procedure to configure the keys to _sign_ and _encrypt_ the data.

Demo Files

• The input-file changed, and we have prepared new demo files to help the users adjust. Since we do not distribute an AllInOne package, you may download the new files:

  • from the console:

    `console co2mpas demo --download `

  • From this link

v2.0.0 (2018-08-31): “Unleash” Release

Changes since 1.7.4.post0:

Breaking:

1. The pip utility contained in the old AIO is outdated (9.0.1) and cannot correctly install the transitive dependencies of new |co2mpas|, even for development purposes. Please upgrade your pip before following the installation or upgrade instructions for developers.

2. The vehicle_family_id format has changed (but old format is still supported):

   OLD: FT-TA-WMI-yyyy-nnnn
   NEW: FT-nnnnnnnnnnnnnnn-WMI-x
   

3. The CO₂MPAS python package has been splitted (see #408), and is now served by 4 python packages listed below. In practice this means that you can still receive bug-fixes and new features for the DICE or the GUI, while keeping the simulation-model intact.

   1. co2sim: the simulator, for standalone/engineering work. Now all IO-libraries and graph-drawing are optional, specified the io & plot “extras”. If you need just the simulator to experiment, you need this command to install/upgrade it with:

      pip install co2sim[io,plot] -U
      

   2. co2dice: the backend & commands for DICE.

   3. co2gui: the GUI.

   4. co2mpas: installs all of the above, and [io,plot] extras.

   The relationships between the sub-projects are depicted below:

   co2sim[io,plot]
     |    |
     |  co2dice
     |  /  \
    co2gui  WebStamper
      |
   co2mpas
   

   Note

   co2sim on startup checks if the old co2mpas-v1.x is still installed, and aborts In that case, uninstall all projects and re-install them, to be on the safe side, with this commands:

   pip uninstall -y co2sim co2dice co2gui co2mpas
   pip install co2sim co2dice co2gui co2mpas -U
   

Model

• feat(co2_emissions): Add engine_n_cylinders as input value and a TA parameter.

• feat(ta): New TA output file.

  Running CO2MPAS in TA mode, will produce an extra file containing the DICE report. This file will be used in the feature version of DICE.

• feat(core): Improve calibration performances 60%.

• feat(manual): Add a manual prediction model according GTR.

• feat(gearbox): Add utility to design gearbox ratios if they cannot be identified based on maximum_velocity and maximum_vehicle_laden_mass.

  This is not affecting the TA mode.

• fix(co2mpas_template.xlsx): The parameter “Vehicle Family ID” changes to “Interpolation Family ID”.

• fix(co2mpas_template.xlsx): Meta data.

  Add additional sheets for meta data. As for September 2018, the user can voluntarily add data related to the all WLTP tests held for a specific Interpolation Family ID. Since this addition is optional, the cells are colored orange.

• fix(vehicle): Default n_dyno_axes as function of n_wheel_drive for wltp (4wd–>2d, 2wd–>1d).

  If nothing is specified, default values now are: n_dyno_axes = 1 n_wheel_drive = 2

  If only n_wheel_drive is selected, then the default for n_dyno_axes is calculated as function of n_wheel_drive for wltp (4wd–>2d, 2wd–>1d)

  If only n_dyno_axes is selected, then the default for n_wheel_drive is always 2.

• fix(vva): Remove _check_vva. engine_has_variable_valve_actuation = True and ignition_type = 'compression' is permitted.

• fix(ki_factor): Rename ki_factor to ki_multiplicative and add ki_additive value.

• fix(start_stop): Disable start_stop_activation_time when has_start_stop == True.

• fix(co2_emission): Disable define_idle_fuel_consumption_model when idle_fuel_consumption is not given.

• fix(ta): Disable function define_idle_fuel_consumption_model and default_start_stop_activation_time.

• fix(electrics): Improve calculation of state of charges.

• fix(at): Correct correct_gear_full_load method using the best gear instead the minimum when there is not sufficient power.

IO Data

• BREAK: Bumped input-file version from 2.2.8 --> 2.3.0. And improved file-version comparison

• CHANGE: Changed vehicle_family_id format, but old format is still supported (#473):

  OLD: FT-TA-WMI-yyyy-nnnn
  NEW: FT-nnnnnnnnnnnnnnn-WMI-x
  

• feat: Input-template provide separate H/L fields for both ki multiplicative and Ki additive parameters.

• drop: remove deprecated co2mpas gui sub-command - co2gui top-level command is the norm since January 2017.

Dice

• FEAT: Added a new “Stamp” button on the GUI, stamping with WebStamper in the background in one step; internally it invokes the new dicer command (see below)(#378).

• FEAT: Added the simplified top-level sub-command co2dice dicer which executes a sequencer of commands to dice new or existing project through WebStamper, in a single step.:

  co2dice dicer -i co2mpas_demo-1.xlsx -o O/20180812_213917-co2mpas_demo-1.xlsx
  

  Specifically when the project exists, e.g. when clicking again the GUI-button, it compares the given files bit-by-bit with the ones present already in the project, and proceeds only when there are no differences. Otherwise (or on network error), falling back to cli commands is needed, similar to what is done with abnormal cases such as --recertify, over-writing files, etc.

• All dice-commands and WebStamper now also work with files, since Dices can potentially be MBs in size; Copy + Paste becomes problematic in these cases.

• Added low-level co2dice tstamp wstamp cli-command that Stamps a pre-generated Dice through WebStamper.

• FEAT: The commands co2dice dicer|init|append|report|recv|parse and co2dice tstamp wstamp, support one or more --write-file <path>/-W options, to and every time they run, they can append or overwrite into all given <path> these 3 items as they are generated/received:

  1. Dice report;
  2. Stamp (or any errors received from WebStamper);
  3. Decision.

  By default, one <path> is always ~/.co2dice/reports.txt, so this becomes the de-facto “keeper” of all reports exchanged (to mitigate a known limitation about not being able to retrieve old stamps). The location of the reports.txt file is configurable with

  • c.ReportsKeeper.default_reports_fpath configuration property, and/or
  • CO2DICE_REPORTS_FPATH (the env-var takes precedence).

• feat: command co2dice project report <report-index> can retrieve older reports (not just the latest one). Negative indexes count from the end, and need a trick to use them:

  co2dice project report -- -2
  

  There is still no higher-level command to retrieveing Stamps (an old known limitation); internal git commands can do this.

• drop: deprecate all email-stamper commands; few new enhancements were applied on them.

• feat(#466, #467, io, dice): Add --with-inputs on co2dice project init|append|report|dicer commands that override flag in user-data .xlsx file, and attached all inputs encrypted in dice.

• feat: add 2 sub-commands in report standalone command:

  co2dice report extract  # that's the old `co2dice report`
  co2dice report unlock   # unlocks encrypted inputs in dice/stamps
  

• feat(dice): all dice commands accept --quiet/-q option that along with --verbose/-v they control the eventual logging-level.

  It is actually possible to give multiple -q / -v in the command line, and the verbose level is an algebraic additions of all of them, starting from INFO level.

  BUT if any -v is given, the Spec.verbosed trait-parameter is set to true. (see #476, #479).

• doc: small fixes on help-text of project commands.

• feat(dice): prepare the new-dice functionality of taring everything (see #480).

  The new flag.encrypt_inputs in input-xlsx file, configured by ENCRYPTION_KEYS_PATH, works for dice-2 but not yet respected by the old-dice commands; must revive 4de77ea1e.

• refact: renamed various internal classes and modules for clarity.

Various

• FIX: Support pip >= 10+ (see #26).
• break: changed cmd-line scripts entry-points; if you install from sources, remember to run first: pip install -e {co2mpas-dir}
• Pinned versions of dependencies affecting the accuracy of the calculations, to achieve stronger reproducibility; these dependent libraries are shiped with AIO (see #427).
• Accurate versioning of project with polyvers.
• feat: provide a docker script, ensuring correct numpy-base+MKL installed in conda requirements.
• WebStamp: split-off v1.9.0a1 as separate sub-project in sources.

Known Limitations

• Reproducibility of results has been greatly enhanced, with quasi-identical results in different platforms (linux/Windows).
• DICE:
  • Fixed known limitation of 1.7.3 (#448) of importing stamps from an older duplicate dice.
  • It is not possible to -recertify from nedc state (when mored files have been appended after stamping).
  • There is still no high level command to view Stamps (see low-level command in the old known limitation item). But stamps received are now save in ~/.co2dice/reports.txt (along with dices and decisions).
  • The decision-number generated still never includes the numbers 10, 20, …90.
  • All previous known limitations regarding mail-stamper still apply. But these commands are now deprecated.

Intermediate releases for 2.0.x:

Note

• Releases with r prefix signify version published in PyPi.
• Releases with v prefix signify internal milestones.

|co2mpas|-r2.0.0.post0, 1 Sep 2018

doc: Just to fix site and PyPi landing page.

r2.0.0, 31 Aug 2018

• fix: hide excess warnings.

co2sim/co2gui: v2.0.0rc3, co2dice/webstamper: v2.0.0rc1, 30 Aug 2018

• FIX: Print remote-errors when WebStamper rejects a Dice.
• fix: WebStamper had regressed and were reacting violently with http-error=500 (“server-failure”) even on client mistakes; now they became http-error=400.
• fix: eliminate minor deprecation warning about XGBoost(seed=) keyword.

v2.0.0rc2 for co2sim & co2gui, 28 Aug 2018

• FIX: add data (xlsx-files & icons) to co2sim & co2gui wheels.
• v2.0.0rc1 tried but didn’t deliver due to missing package-data folders.

v2.0.0rc0, 24 Aug 2018

• DROP: make co2deps pinning-versions project disappear into the void, from where it came from, last milestone. Adding a moribund co2-project into PyPi (until pip bug pypa/pip#3878 gets fixed) is a waste of effort.
• ENH: extracted plot extras from co2sim dependencies. Significant work on all project dependencies (#408, #427 & #463). Coupled with the new wltp-0.1.0a3 & pandalone-0.2.4.post1 releases, now it is possible to use CO₂MPAS-simulator with narrowed-down dependencies (see docker-image size reduction, above).
• REFACT: separated DICE from SIM subprojects until really necessary (e.g. when extracting data from appended files). Some code-repetition needed, started moving utilities from __main__.py into own util-modules, at least for co2dice.
• ENH: update alpine-GCC in docker with recent instructions,and eventually used the debian image, which ends up the same size with less fuzz. Docker-image co2sim wheel is now created outside of docker with its proper version-id of visible; paths updated, scripts enhanced, files documented.
• ENH: setup.py does not prevent from running in old Python versions (e.g to build wheels in Py-2, also in #408).
• feat: dice-report encryption supports multiple recipients.
• feat: gui re-reads configurations on each DICE-button click.
• chore: add GNU Makefiles for rudimentary support to clean, build and maintain the new sub-projectrs.

v2.0.0b0, 20 Aug 2018

• BREAK: SPLIT CO2MPAS(#408) and moved packages in .sub-dir/src/:

  1. co2sim[io]: root/pCO2SIM
  2. co2dice: root/pCO2DICE
  3. co2gui: root/pCO2GUI
  4. co2deps: root/pCO2DEPS
  5. co2mpas[pindeps]: root
  6. WebStamper: root/pWebStamper

  • Also extracted io extras from co2sim dependencies.

• enh: use GNU Makefile for developers to manage sub-projects.

• enh: Dice-button reloads configurations when clicked (e.g. to read WstampSpec.recpients parameter if modified by the user-on-the-spot).

• enh: dice log-messages denote reports with line-numberss (not char-nums).

Intermediate releases for 1.9.x:

v1.9.2rc1, 16 Aug 2018

• FIX: GUI mechanincs for logs and jobs.
• fix: finalized behavior for button-states.
• enh: possible to mute email-stamper deprecations with EmailStamperWarning.mute.
• enh: RELAX I/O file-pairing rule for dicer cmd, any 2 io-files is now ok.

v1.9.2rc0, 14 Aug 2018 (BROKEN GUI)

• ENH: Add logging-timestamps in ~/.co2dice/reports.txt maintained by the ReportsKeeper`(renamed from ``FileWritingMixin`) which now supports writing to multiple files through the tested logging library.

• enh: make location of the reports.txt file configurable with:

  • c.ReportsKeeper.default_reports_fpath property and
  • CO2DICE_REPORTS_FPATH (env-var takes precedence).

• REFACT: move DicerCMD (& DicerSpec) in their own files and render them top-level sub-commands. Also renamed modules:

  • baseapp --> cmdlets not to confuse with base module.
  • dice --> cli not to confuse with dicer module and the too-overloaded :term;`dice`.

• enh: replace old output-clipping machinery in tstamp recv with shrink-slice.

• enh: teach GUI to also use HTTP-sessions (like dicer command does).

• GUI-state behavior was still not mature.

r1.9.1b1, 13 Aug 2018

• FIX: project dicer command and GUI new Dice-button were failing to compare correctly existing files in project with new ones.

  Enhanced error-reporting of the button.

• doc: Update DICE-changes since previous major release.

• doc: Add glossary terms for links from new data in the excel input-file .

• doc: updated the dice changes for the forthcoming major-release, above

• dev: add “scafolding” to facilitate developing dice-button.

v1.9.1b0, 10 Aug 2018

• FEAT: Finished implementing the GUI “Stamp” button (it appends also new-dice tar, see #378).
• Retrofitted project dice command into a new “DICER” class, working as a sequencer of commands to dice new or existing projects through WebStamper only. Specifically now it compares the given files with the ones already in the project. Manual intervention is still needed in abnormal cases (--recertify, over-writing files, etc).

• Added WebAPI + co2dice tstamp wstamp cli-commands to check stamps and

  connectivity to WebStamper.

• Renamed cmd project dice --> dicer not to overload the dice word; it is

  a sequencer after all.

• feat: rename -W=~/co2dice.reports.txt --> ~/.co2dice/reports.txt to reuse dice folder.
• drop: removed co2dice project tstamp command, deprecated since 5-may-2017.
• enh: project dicer cmd uses HTTP-sessions when talking to WebStamper, but not the GUI button yet.
• fix: -W--write-fpath works more reliably, and by defaults it writes into renamed ~/.co2dice/reports.txt.

v1.9.1a2, 10 Aug 2018

Fixes and features for the GUI Stamp-button and supporting project dice command.

• FEAT: co2dice project dicer|init|append|report|recv|parse and the co2dice tstamp wstamp commands, they have by default --write-file=~/.co2dice/reports.txt file, so every time they run, they APPENDED into this file these 3 items:

  1. Dice report;
  2. Stamp (or any errors received from the WebStamper);
  3. Decision.

• doc: deprecate all email-stamper commands; few new enhancements were applied on them.

• drop: remove deprecated co2mpas gui cmd - co2gui is the norm since Jan 2017.

• doc: small fixes on help-text of project commands.

• refact: extract dice-cmd functionality into its own Spec class.

• sources: move tkui.py into it’s own package. (needs re-install from sources).

• WIP: Add GUI “Stamp” button that appends also new-dice tar (see #378).

v1.9.1a1, 10 Aug 2018

Implement the new project dice command.

• Work started since v1.9.1a0: 8 Aug 2018.
• FEAT: NEW WEB-API CMDS: - co2dice project dicer: Dice a new project in one action through WebStamper. - tstamp wstamp: Stamp pre-generated Dice through WebStamper.
• feat: co2dice project report command can retrieve older reports. (not just the latest). For Stamps, internal git commands are still needed.
• WIP: Add GUI “Stamp” button.

r1.9.0b2, 7 Aug 2018

Version in PyPi deemed OK for release. Mostly doc-changes since b1.

v1.9.0b1, 2 Aug 2018

More changes at input-data, new-dice code and small model changes. Not released in PyPi.

• feat(dice): teach the options --write-fpath/-W and --shrink to the commands:

  co2dice project (init|append|report|parse|trecv)
  

  so they can write directly results (i.e. report) in local files, and avoid printing big output to the console (see #466). WebStamper also works now with files, since files can potentially be Mbs in size.

• feat(dice): teach dice commands --quiet/-q option that along with --verbose/-v they control logging-level. It is actually possible to give multiple -q / -v in the command line, and the verbose level is an algebraic additions of all of them, starting from INFO level. BUT if any -v is given, the Spec.verbosed trait-parameter is set to true. (see #476, #479).

• feat(dice): prepare the new-dice functionality of taring everything (see #480). Add flag.encrypt_inputs in input-xlsx file, configured by ENCRYPTION_KEYS_PATH, but not yet respected by the dice commands; must revive 4de77ea1e.

• feat(WebStamper): Support Upload dice-reports from local-files & Download Stamp to local-files.

• fix(dice): fix redirection/piping of commands.

• fix(site): Update to latest schedula-2.3.x to fix site-generation (see #476, e534168b).

• enh(doc): Update all copyright notices to “2018”.

• refact(sources): start using __main__.py also for dice, but without putting too much code in it, just for PEP 366 relative-imports to work.

r1.9.0b0, 31 Jul 2018

1st release with new-dice functionality.

v1.9.0a2, 11 Jul 2018

• WebStamp: split-off v1.9.0a1 as separate sub-project in sources.

IO Data

• IO: Input-template provide separate H/L fields for both ki multiplicative and Ki additive parameters.

v1.9.0a1, 5 Jul 2018

Bumped minor number to signify that the VF_ID and input-file version have changed forward-incompatibly. Very roughly tested (see #472). (v1.9.0a0 was a checkpoint after VF_ID preliminary changes).

• CHANGE: Changed vehicle_family_id format, but old format is still supported (#473):

  OLD: FT-TA-WMI-yyyy-nnnn
  NEW: FT-nnnnnnnnnnnnnnn-WMI-x
  

• BREAK: Bumped input-file version from 2.2.8 --> 2.3.0. And improved file-version comparison (Semantic Versioning)

• fix: completed transition to polyversion monorepo scheme.

• docker: ensure correct numpy-base+MKL installed in conda requirements.

Model

• FIX: Gear-model does not dance (#427).
• fix: remove some pandas warnings

Intermediate releases for 1.8.x:

v1.8.1a2, 12 Jun 2018

Tagged as co2mpas_v1.8.1a0 just to switch polyversion repo-scheme, from mono-project –> monorepo (switch will complete in next tag).

• feat(#466, #467, io, dice): Add --with-inputs on report commands that override flag in user-data .xlsx file, and attached all inputs encrypted in dice.

• Add 2 sub-commands in report standalone command:

  co2dice report extract  # that's the old `co2dice report`
  co2dice report unlock   # unlocks encrypted inputs in dice/stamps
  

• testing #375: - dice: need pytest to run its TCs. - dice: cannot run all tests together, only one module by one. All pass

v1.8.0a1, 7 Jun 2018

• FIX dice, did not start due to polyversion not being engraved.

• The CO2MPARE_ENABLED fails with:

  ERROR:co2mpas_main:Invalid value '1' for env-var[CO2MPARE_ENABLED]!
    Should be one of (0 f false n no off 1 t true y yes on).
  

v1.8.0a0, 6 Jun 2018

PINNED REQUIRED VERSIONS, served with AIO-1.8.1a1

v1.8.0.dev1, 29 May 2018

• chore:(build, #408, 0761ba9d6): Start versioning project with polyvers tool, as mono-project.
• feat(data, #???): Implemented co2mparable generation for ex-post reproducibility studies.

v1.8.0.dev0, 22 May 2018

Included in 1st AIO-UpgradePack (see #463).

• chore(build, e90680fae): removed setup_requires; must have these packages installed before attempting to install in “develop mode”:

  pip, setuptools setuptools-git >= 0.3, wheel, polyvers
  

• feat(deps): Add xgboost native-lib dependency, for speed.

Pre-v1.8.0.dev0, 15 Nov 2017

• feat(model): Add utility to design gearbox ratios if they cannot be identified based on maximum_velocity and maximum_vehicle_laden_mass. This is not affecting the TA mode.
• feat(model): Add function to calculate the vehicle_mass from curb mass, cargo_mass, curb_mass, fuel_mass, passenger_mass, and n_passengers. This is not affecting the TA mode.
• Dice & WebStamper updates…

Intermediate releases for 1.7.x:

v1.7.4.post3, 10 Aug 2018

Settled dependencies for pip and conda environments.

v1.7.4.post2, 8 Aug 2018

• Fixed regression by “piping to stdout” of previous broken release 1.7.1.post1.

• Pinned dependencies needed for downgrading from v1.9.x.

  Transitive dependencies are now served from 2 places:

  • setup.py: contains bounded dependency versions to ensure proper functioning, but not reproducibility.

    These bounded versions apply when installing from PyPi with command pip instal co2mpas==1.7.4.post2; then pip will install dependencies with as few as possible transitive re-installations.

  • requirements/exe.pip & requirements/install_conda_reqs.sh: contain the pinned versions of all calculation-important dependent libraries (see #463).

    You need to get the sources (e.g. git-clone the repo) to access this file, and then run the command pip install -r <git-repo>/requirements/exe.pip.

v1.7.4.post1, 3 Aug 2018 (BROKEN!)

Backport fixes to facilitate comparisons with forthcoming release 1.9+.

• Support pip >= 10+ (fixes #26).
• Fix conflicting dill requirement.
• Fix piping dice-commands to stdout.

v1.7.4.post0, 11 Dec 2017

Never released in PyPi, just for fixes for WebStamper and the site for “Toketos”.

• feat(wstamp): cache last sender+recipient in cookies.

v1.7.4, 15 Nov 2017: “Toketos”

• feat(dice, #447): Allow skipping tsend -n command to facilitate WebStamper, and transition from tagged –> sample / nosample.
• fix(co2p, #448): tparse checks stamp is on last-tag (unless forced). Was a “Known limitation” of previous versions.

v1.7.3.post0, 16 Oct 2017

• feat(co2p): The new option --recertify to co2dice project append allows to extend certification files for some vehile-family with new ones

  Note

  The old declaration-files are ALWAYS retained in the history of “re-certified” projects. You may control whether they old files will be also visible in the new Dice-report or not.

  For the new dice-report to contain ALL files (and in in alphabetical-order), use different file names - otherwise, the old-files will be overwritten. In the later case, the old files will be visible only to those having access to the whole project, such as the TAAs after receiving the project’s exported archive.

• fix(co2p): co2dice project commands were raising NPE exception when iterating existing dice tags, e.g. co2dice project export . to export only the current project raised:

  AttributeError: 'NoneType' object has no attribute 'startswith'
  

• fix(tstamp): co2dice tstamp were raising NPE exceptions when -force used on invalid signatures.

Known Limitations

co2dice(#448): if more than one dice-report is generated for a project, it is still possible to parse anyone tstamp on the project - no check against the hash-1 performed. So practically in this case, the history of the project is corrupted.

v1.7.3, 16 August 2017: “T-REA” Release

• Dice & model fine-tuning.
• Includes changes also from RETRACTED v1.6.1.post0, 13 July 2017, “T-bone” release.

DICE

• feat(config): stop accepting test-key ('CBBB52FF'); you would receive this error message:

  After July 27 2017 you cannot use test-key for official runs!
  
  Generate a new key, and remember to re-encrypt your passwords with it.
  If you still want to run an experiment, add `--GpgSpec.allow_test_key=True`
  command-line option.
  

  You have to modify your configurations and set GpgSpec.master_key to your newly-generated key, and re-encrypt your passowords in persist file.

• feat(config): dice commands would complain if config-file(s) missing; remember to transfer your configurations from your old AIO (with all changes needed).

• feat(AIO): prepare for installing AIO in multi-user/shared environments; the important environment variable is HOME (read [AIO]/.co2mpad_env.bat file and run co2dice config paths command). Enhanced Cmd.config_paths parameter to properly work with persistent JSON file even if a list of “overlayed” files/folders is given.

• feat(config): enhance co2dice config (desc | show | paths) commands to provide help-text and configured values for specific classes & params and all interesting variables affecting configurations. (alternatives to the much coarser --help and --help-all options).

• Tstamping & networking:

  • feat(#382): enhance handling of email encodings on send/recv:

    • add configurations choices for Content-Transfer-Enconding when sending non-ASCII emails or working with Outlook (usually ‘=0A=0D=0E’ chars scattered in the email); read help on those parameters, with this command:

      co2dice config desc transfer_enc  quote_printable
      

    • add TstampSender.scramble_tag & TstampReceiver.un_quote_printable options for dealing with non-ASCII dice-reports.

  • (t)recv cmds: add --subject, --on and --wait-criteria options for search criteria on the tstamp recv and project trecv subcmds;

  • (t)recv cmds: renamed email_criteria-->rfc-criteria, enhancing their syntax help;

  • (t)parse can guess if a “naked” dice-reports tags is given (specify --tag to be explicit).

  • (t)recv cmd: added --page option to download a “slice” of from the server.

  • improve (t)parse command’s dice printout to include project/issuer/dates.

  • (t)recv: BCC-addresses were treated as CCs; --raw STDOUT was corrupted; emails received

  • feat(report): print out the key used to sign dice-report.

• Projects:

  • feat(project): store tstamp-email verbatim, and sign 2nd HASH report.

  • refact(git): compatible-bump of dice-report format-version: 1.0.0-->1.0.1.

  • feat(log): possible to modify selectively logging output with ~/logconf.yaml file; generally improve error handling and logging of commands.

  • co2dice project export:

    • fix(#18): fix command not to include dices from all projects.

    • feat(#423, #435): add --out option to set the out-fpath of the archive, and the --erase-afterwards to facilitate starting a project.

      Note

      Do not (ab)use project export --erase-afterwards on diced projects.

  • co2dice project open: auto-deduce project to open if only one exists.

  • co2dice project backup: add --erase-afterwards option.

Known Limitations

• Microsoft Outlook Servers are known to corrupt the dice-emails; depending on the version and the configurations, most of the times they can be fixed. If not, as a last resort, another email-account may be used. A permanent solution to the problem is will be provided when the the Exchange Web Services (EWS) protocol is implemented in |co2mpas|.

• On Yahoo servers, the TstampReceiver.subject_prefix param must not contain any brackets ([]). The are included by default, so you have to modify that in your configs.

• Using GMail accounts to send Dice may not(!) receive the reply-back “Proof of Posting” reply (or it may delay up to days). Please perform tests to discover that, and use another email-provided if that’s the case. Additionally, Google’s security provisions for some countries may be too strict to allow SMTP/IMAP access. In all cases, you need to enable allow less secure apps to access your account.

• Some combinations of outbound & inbound accounts for dice reports and timsestamps may not work due to DMARC restrictions. JRC will offer more alternative “paths” for running Dices. All major providers (Google, Yahoo, Microsoft) will not allow your dice-report to be stamped and forwarded to TstampSender.stamp_recipients other than the Comission; you may (or may not) receive “bounce” emails explaining that.

• There is no high level command to view the stamp for some project; Assuming your project is in sample or nosample state, use this cmd:

  cat %HOME%/.co2dice/repo/tstamp.txt
  

• The decision-number generated never includes the numbers 10, 20, …90. This does not change the odds for SAMPLE/NOSAMPLE but it does affect the odds for double-testing Low vs High vehicles (4 vs 5).

Datasync

• #390: Datasync was producing 0 values in the first and/or in the last cells. This has been fixed extending the given signal with the first and last values.
• #424: remove buggy interpolation methods.

Model-changes

• d21b665, 5f8f58b, 33538be: Speedup the model avoiding useless identifications during the prediction phase.

Vehicle model

• d90c697: Add road loads calculation from vehicle and tyre category.
• 952f16b: Update the rolling_resistance_coeff according to table A4/1 of EU legislation not world wide.
• 952f16b: Add function to calculate aerodynamic_drag_coefficient from vehicle_body.

Thermal model

• #169: Add a filter to remove invalid temperature derivatives (i.e., abs(DT) >= 0.7) during the cold phase.

Clutch model

• #330: Some extra RPM (peaks) has been verified before the engine’s stops. This problem has been resolved filtering out clutch_delta > 0 when acc < 0 and adding a features selection in the calibration of the model.

Engine model

• 4c07751: The auxiliaries_torque_losses are function of engine_capacity.

CO2 model

• #350: Complete fuel default characteristics (LHV, Carbon Content, and Density).
• 2e890f0: Fix of the bug in tau_function when a hot cycle is given.
• #399: Implement a fuzzy rescaling function to improve the stability of the model when rounding the WLTP bag values.
• #401: Set co2_params limits to avoid unfeasible results.
• #402: Rewrite of calibrate_co2_params function.
• #391, #403: Use the identified_co2_params as initial guess of the calibrate_co2_params. Update co2 optimizer enabling all steps in the identification and disabling the first two steps in the calibration. Optimize the parameters that define the gearbox, torque, and power losses.

IO & Data:

• fix(xlsx, #426): excel validation formulas on input-template & demos did not accept vehicle-family-id with single-digit TA-ids.
• #314, gh:410: MOVED MOST DEMO-FILES to AIO archive - 2 files are left. Updated |co2mpas| demo command to use them if found; add --download option to get the very latest from Internet.
• main: rename logging option --quite –> --quiet.
• #380: Add cycle scores to output template.
• #391: Add model scores to summary file.
• #399: Report co2_rescaling_scores to output and summary files.
• #407: Disable input-file caching by default (renamed option --override-cache --> use-cache.

Known Limitations

• The co2mpas modelgraph command cannot plot flow-diagrams if Internet Explorer (IE) is the default browser.

GUI

• feat: co2gui command does not block, and stores logs in temporary-file. It launches this file in a text-editor in case of failures.
• feat: remember position and size between launches (stored in persistent JSON file).

AIO

• Detect 32bit Windows early, and notify user with an error-popup.
• Possible to extract archive into path with SPACES (not recommended though).
• Switched from Cygwin–>MSYS2 for the POSIX layer, for better support in Windows paths, and pacman update manager. Size increased from ~350MB –> ~530MB.
  • feat(install): reimplement cygwin’s mkshortcut.exe in VBScript.
  • fix(git): use cygpath.exe to convert Windows paths and respect mount-points (see GitPython#639).
• Use [AIO] to signify the ALLINONE base-folder in the documentation; use it in CO₂MPAS to suppress excessive development warnings.

Indices and tables

• Index
• Module Index
• Search Page