WO2017202947A2

WO2017202947A2 - Method and system for determining the fuel consumptions actually resulting from the everyday operation of road vehicles, energy inputs and emissions

Info

Publication number: WO2017202947A2
Application number: PCT/EP2017/062600
Authority: WO
Inventors: Michael Feldmann
Original assignee: Phoenix Ip Bv I.O.
Priority date: 2016-05-25
Filing date: 2017-05-24
Publication date: 2017-11-30
Also published as: WO2017202947A3; EP3465633A2

Abstract

The invention relates to a method and a system for determining the fuel consumptions actually resulting from the everyday operation of road vehicles, to energy inputs and emissions.

Description

fuel consumption, energy inputs and emissions

Description Technical area

The invention relates to a method and a system for determining the fuel consumption, energy inputs and emissions actually generated in everyday operation of road vehicles.

background

Transport is the basis of our society and economy. Mobility is the lifeblood of the European internal market, it shapes the quality of life of citizens who enjoy their freedom of travel. Efficient mobility is also a prerequisite for economic prosperity. No traffic is not an option, free travel is and remains a basic need of the people. However, given the limitations of resources and environmental concerns, society, politics and players in the mobility industry are called upon to meet the travel needs of citizens and the freight transport needs of our economy in a new way.

In December 2015, the international community decided in Paris to limit the rise in the average temperature of the Earth's atmosphere to below 2 ° C, thereby limiting climate change. To achieve this goal, the EU must reduce greenhouse gas emissions by 80% to 95% by 2050 compared to 1990 levels. In the transport sector, where the reduction of GHG emissions is particularly difficult due to a lack of alternatives, emission reductions should reach at least 60% by 2050 compared to 1990 levels, which is 70% of the 2008 level.

Cities suffer the most from congestion, poor air quality and noise pollution. Urban traffic accounts for around a quarter of traffic-related C0 ₂ emissions. The progressive reduction in the share of conventionally driven vehicles and the distances covered by fossil fuels, particularly in cities, is a major contribution to reducing greenhouse gas emissions, local air pollution and noise pollution.

Despite technological progress, the European transport system has not changed fundamentally. It is not sustainable. While transport has become more energy efficient, it still accounts for approximately 96% of oil and oil-based fuels in the EU. Transport has also become more environmentally friendly, but increasing traffic has more than compensated for this positive development.

For individual modes of transport, the EU has adopted various rules and regulations to limit fuel consumption and emissions of greenhouse gases, particulate matter and nitrogen oxides, which are prerequisites for the registration and sale of motor vehicles. In order to standardize and compare the determination of fuel consumption and emissions, driving cycles have been defined which determine with what speed sequences and under what conditions a motor vehicle must be operated in the determination of fuel or energy input and emissions.

Such boundary conditions are eg vehicle preparation (conditioning), payload, starting temperature, driving speed, for vehicles with manual transmission the determination of the switching points, start of the exhaust gas measurement and other parameters. The driving cycles are usually driven on a chassis dynamometer. Driving cycles should produce as realistic a load as possible, which is a more or less realistic average profile. This procedure makes it possible to obtain reproducible and comparable results. Such driving cycles offer motor vehicle manufacturers development security. They are also relevant for making diagnoses and determining exhaust emissions. In the EU, the legally binding measurements may only be carried out by certified EC testing laboratories. In Germany, the certification of these test laboratories by the Federal Motor Transport Authority.

In order to determine the fuel consumption of a motor vehicle, the driving resistances (rolling and aerodynamic drag) of the motor vehicle are first determined on the road. The measured driving resistances are then transferred to a chassis dynamometer. These driving resistances are used to drive a standardized driving cycle. The emission data are measured. Subsequently, the stoichiometric fuel consumption is calculated from the exhaust emission. In electric cars, the charge states of the battery are measured instead.

Emission standards and a driving cycle were first established in Germany and France at the end of the 1960s, and were subsequently adopted in Directive 70/220 / EEC of March 1970. After the first oil crisis in 1976, the new DIN 70030 integrated in 1978 a new method for measuring fuel consumption, according to which first a driving cycle simulated the city traffic and additional constant speeds of 90 km / h and still 120 km / h in the laboratory were driven. From these three values, an arithmetic mean, the so-called one-third mix, was formed. Previously, the precursor DIN 70020 had stipulated that it was only possible to measure at one speed and without a city driving cycle. In 1992, the cycle of urban transport laid down in Directive 70/220 / EEC was extended to cover the roads and motorways. This extended driving cycle is also known as the New European Driving Cycle (NEDC).

Since 1997, fuel consumption has been calculated stoichiometrically from the amount of exhaust gas determined in the NEDC. The fuel consumption determined in this way proved to be about 8% higher than the value previously determined by a one-third mix. At the same time as the introduction of the new EU exhaust standard "Euro 3", the NEDC did not adopt the Modified New European Driving Cycle (MNEFZ), which stipulates that the measurement at 20 ° C - 30 ° C should begin with a cold start before after a 40 second warm-up phase.

The standardized driving cycle lasts 1,180 seconds. The city traffic cycle occupies two thirds of this time and the overland cycle corresponding to one third. Cold start condition, accelerations and decelerations are detected and interpolated. The new test method is intended to introduce the measured fuel and energy consumption and thus the emissions closer than the realities of everyday operation. But there are few provisions that prohibit automakers from working with off-the-shelf fuel-efficiency measures. The use of low-viscosity oils and the use of so-called fuel-saving tires represent such everyday measures.

According to the NGO Transport and Environment (T & E), a European umbrella organization of non-governmental organizations, associations and institutes dedicated to sustainable transport, the following (permitted) measures are taken to reduce fuel consumption during the implementation of the driving cycle in addition to the use of low-viscosity oils and fuel-saving tires usual: Masking of joints of the outer shell, change the lane and camber of the wheels, increase the air pressure in the car tires, use of the minimum vehicle weight, relinquishing the recharging of the vehicle battery (disconnecting the alternator), switching off the heating or air conditioning, avoidance of grinding brakes, adjustment of the motor control, deduction of a 4% measuring tolerance. As a result, these measures reduce fuel consumption by 10% - 30%. In the EU, the fuel consumption and emission values determined in this way were not questioned until the VW emissions scandal in 2015. In addition to the measures to reduce fuel consumption on the chassis dynamometer, which are considered as permitted by the driving cycle regulations, there is a fundamental problem: the driving cycle is usually inconsistent with the driver's actual use in everyday operation, especially if the share of the driver Short haul and / or city traffic is high in total usage. The fuel consumption and the associated emissions arising at speeds above 120 km / h are not measured at all and thus are not included in the calculation of the average values. The deviations become greater, the less favorable the aerodynamics of a motor vehicle and the faster it is moved.

In addition, the acceleration dynamics applied in the driving cycle (from 0 to 50 km / h in 26 seconds) is not realistic, in everyday life is accelerated much more and i.d. R. also at higher speeds - which leads to higher fuel consumption and higher emissions. The deviations are higher, the larger the vehicle masses fail, for SUV result in the driving cycle significantly lower fuel consumption than in everyday practice. As the German Automobile Club ADAC has determined through tests, the fuel consumption and emission values determined on the chassis dynamometers according to the prescribed driving cycle are 25% - 40% too low compared to the values resulting from everyday operation.

Accordingly, the political and technical discussion increasingly distinguishes between official consumption and emission values and those of "real operation." The European Research Group on Mobile Emission Sources (ERM ES) represents and is responsible for a merger of independent European institutions for the "development" of so-called road traffic emission factors, for example, in its 4-page information document "Diesel light duty vehicle NO _x emission factors" of 9 October 2015: "As a summary, current real-world Euro 6 emission levels to go higher than the average level of the emission factors used in the project (6) vehicle models to capture actual emission levels. We need to perform on-road and chassis dynamometer tests in the lab, especially for Euro 5 vehicles, in order to capture the magnitude of a posibly sy stematic difference between in-lab and on-road emission levels, in order to possibly correct existing emission factors. We have limited information, eg on how aged emission control systems. ... Issues are therefore known in the area of greenhouse gas control, Including Increasing of deviation between real-world and type-approval CO emission, our very limited knowledge of N ₂ 0 emission, and others. ... Current, unfortunate, developments have shown that independent monitoring of vehicle emission levels continues to be absolutely necessary. "

The WLTC (Worldwide Harmonized Light Vehicles Test Cycle) is intended to provide more realistic information than previous driving cycles. Following a decision of the Environment Committee of the European Parliament, this driving cycle should enter into force in 2017. A veto by the German Federal Government has temporarily stopped this plan. Experts expect that the fuel consumption and emission values determined in accordance with WLTC will be up to 25 percent higher than those calculated according to N ECt.

Fuel consumption and emission values determined on chassis dynamometers are particularly critical when the automobile manufacturer builds computer programs in the engine control units which recognize that the motor vehicle is on a test bench. The engine control is then with another, fuel-saving eco-program (VW scandal). Also counterproductive is that of many car manufacturers from a certain ambient temperature, (<10 ° C, partial already <17 ° C) from a certain vehicle speed (> 145 km / h) or from a certain air pressure (<900 hp) in the engine control programmed off or downshifting of the vehicle's internal systems to reduce the nitrogen oxide emission (extended diesel -Scandal).

It becomes even more problematic or less realistic in the determination of energy consumption and emissions of electric vehicles. These are determined by ECE standard R 101, which uses the following formula for Plugln hybrid vehicles: C = (D _e x OL + D _av x C ₂ ) / (D _e + D _av ) where "C" is the Total consumption in liters / 100 km corresponds to ,, Ci 'the fuel consumption with fully charged battery, "C ₂ " the fuel consumption when the battery is empty, "D _e " the purely electric range and "D _av " of 25 km assumed average distance between two battery charges. The 11-kilometer drive cycle includes city and cross-country driving through the plug-in vehicles twice, once with full batteries and electric motor, and once with dead batteries and internal combustion engine. Currently, the two consumption values determined in this way are added together, with the electrical energy consumed in electrical operation not counting as fuel and entering into the total value with zero. This procedure does not take into account the greenhouse gas, nitrogen oxide, nitrous oxide and particulate matter emissions associated with the generation of electrical energy.

The approach used so far in the determination of fuel consumption and emissions is contrary to the fuel directives issued by the EU. In the meantime, the view has prevailed in science and politics that GHG emissions, in particular, can not be determined by means of the chemical processes taking place stoichiometrically in the internal combustion engine, but according to the life cycle analysis (LCA) which governs GHGs - takes into account emissions from the entire production and use path of the fuel. The system boundaries were thus extended.

Here and in the following, "life cycle greenhouse gas emissions" or (LCA) greenhouse gas emissions (abbreviated (LCA) GHG emissions) are understood to mean what the EU Commission or the EU Parliament and the Council in the EU Directive 98/70 / EC, which are also referred to as "life cycle greenhouse gas intensities" (see EU Directive 2015/652 / EC). If the term "(LCA) GHG emission" is used here and in the following, this means that it can be both the stoichiometric GHG emissions considered so far and LCA GHG emissions; values are used, which is an easy exercise for one of ordinary skill in the art.

The new approach was introduced by the European Parliament and the Council on 13 October 1998 in the form of "life cycle greenhouse gas emissions" and via the EU Directive 98/70 / EC. As a life cycle greenhouse gas emissions understands this EU directive "all C0 _2, CH ₄ - and N ₂ 0 net emissions attributable to the fuel, including any component or fuel added thereto, covering all relevant phases from extraction to cultivation, including land-use change, transport and distribution, through to processing and incineration, irrespective of this Place where these emissions occur. " This is measured or indicated in C0 ₂ equivalents (C0 ₂ -eq).

In addition, EU Directive 98/70 / EC also states that suppliers of electric power for use in road vehicles should also be able to contribute to the reduction of GHG emissions.

Accordingly, under "greenhouse gas emissions per unit of energy" or also "GHG emissions / energy unit", the "total mass of fuel or energy carrier domestic gas emissions in the above sense in C0 ₂ equivalent divided by the total energy content of the fuel or energy carrier (for fuels expressed as lower net calorific value) "understood.

In the following, "GPS" is understood to mean any of the known Global Positioning Systems, that is to say the US-American NAVSTAR GPS, the European GALILEO GPS, the Russian GLONASS GPS and the Chinese BEIDOU GPS.

The consideration of the system "fuel production and use" for all types of road vehicles is therefore no longer confined to the system boundaries or the "Tank to Wheel" (TtW) route but to the extended system boundaries or the "Well to Tank "(WtT), so in total on the route" Well to Wheel "(WtW). In this context, "Well" stands for the actual source or source of the propulsion energy (and the GHG emissions associated with production or cultivation) and "Wheel" for the propulsion energy arriving at the wheel (and the resulting GHG emissions). emissions).

As described above, previously practiced methods for determining the fuel consumption and the energy use and the resulting greenhouse gas (GHG) emissions of road vehicles to more or less serious deficiencies, ie, they form the actually occurring in everyday operation fuel consumption (electricity consumption) and emissions (greenhouse gases , Nitrogen oxides, nitrous oxide, benzene, particulate matter). This is a technical problem. As a result, the values published by automobile manufacturers on the fuel and energy use and on the GHG emission of the motor vehicles manufactured by them are in agreement i.d.R. do not match the values that drivers and owners of these vehicles actually achieve in everyday practical use. In addition, published GHG emissions only include local (stoichiometric) GHG emissions due to incineration, lack of recovery, cultivation, land-use change, feedstock pre-treatment, feedstock conversion, transport, GHG emissions from distribution and incineration.

Thus, there is still a considerable discrepancy between the fuel consumption values of road vehicles and their (LCA) GHG emissions, which are typically determined by the driving cycle, and the actual fuel consumption values and GHG emissions of these road vehicles during everyday operation (real operation).

State of the art

First, methods and devices are known which detect various parameters of engines, in particular internal combustion engines, use for engine control and / or record. Such methods and devices include, but are not limited to, those for measuring and regulating the engine exhaust gases. The collected data is used to control the operation of these engines, to document the course of the operation or to situate exhaust gas compositions.

US Patent US 6470676 (Dölling & Hoffmann) discloses a method and system for exhaust aftertreatment. They propagate a load- and pollutant-level-dependent injection of a reducing agent (selective catalytic reduction). The reducing agent reacts with the nitrogen oxides contained in the exhaust gas (NO _x ) to water (H ₂ 0) and nitrogen (N ₂ ). The catalyst connected in the exhaust gas stream is used to temporarily store unneeded amounts of reducing agent as the engine load decreases. When the engine load increases again, the reducing agent is immediately available, so it is avoided _NOx slip. The teaching of US6470676 refers only to the internal control of exhaust aftertreatment. Neither data (fuel data, engine data, exhaust gas data) are stored nor are they exported. advantage. Furthermore, they can not capture the fuel consumption generated during a particular route, nor the cumulative exhaust gas emissions resulting from that route, nor the (LCA) GHG emissions generated during extraction, cultivation, land-use change, pre-treatment ( Digestion) of the feedstock, resulting in the conversion of the feedstock, during transport and distribution of the fuel.

DE112009000544T5 (Danby et al) discloses an improved method and system for exhaust aftertreatment. In order to comply with legal limits relating to the emission of pollutants contained in the exhaust of internal combustion engines, Danby et al. the load-dependent recirculation of exhaust gas into the engine for the second combustion and the and load and pollutant level dependent injection of a reducing agent (selective catalytic reduction) in the exhaust stream. The DE112009000544T5 has only on the internal control of exhaust aftertreatment content. Neither data (fuel data, engine data, exhaust gas data) are stored nor exported. Furthermore, Danby et al. do not capture the fuel consumption generated during a particular route, nor the cumulative amounts of exhaust gas resulting from this route. The LCA GHG emissions associated with extraction, cultivation, land-use change, pre-treatment (digestion) of the feedstock, conversion of feedstock, transportation and distribution of the fuel are out of reach, as in US6470676 the invention.

CA2131865 (Jack et al.) Discloses a stationary optical system for measuring the gas composition of automotive exhaust plumes, with the vehicles passing the metering system. An infrared light beam is passed through the plume and then impinges simultaneously on a row of closely positioned photocells which detect different wavelengths. The wavelengths correspond to the spectral absorption peaks of the gases CO, C0 ₂ and other gaseous hydrocarbons (H _m C _n ). Based on the measurements of the photocells, a computer calculates vehicle-specific the percentage composition of the exhaust gases. A video camera detects the license plate of the measured motor vehicle. The video image and the gas composition are saved. Although the CA2131865 method and system can provide vehicle-specific data to off-board data stores, only snapshots of the composition of the exhaust gases. Neither can they record the fuel consumption generated during a particular route, nor the cumulative exhaust gas emissions resulting from this route, nor the LCA GHG emissions associated with extraction, cultivation, land-use change, pre-treatment (digestion) of the feedstock, or Conversion of the feed, incurred during transport and distribution of the fuel.

DE 102007042749 A1 (Tabares & Zapatero) describes a method and a device for determining the specific emission of nitrogen oxides (NO _x ) as a performance-dependent exhaust gas code of an internal combustion engine. Tabares / Zapatero determine this NO _x characteristic from the two operating parameters nitrogen oxide mass flow and engine output, whereby they do not directly but indirectly determine these two operating parameters. They derive the operating parameters from parameters that are easier to measure, eliminating the need for complicated and time-consuming attachments and sensors. The indirect determination of the nitrogen oxide mass flow takes place by means of commercially available NO _x sensors via the measurement of the nitrogen oxide volume concentration. The water contained in the exhaust gas stream is ignored. To correct this, the measurement results are multiplied by a dry / wet correction factor. From the thus formed NO _x concentration of the moist exhaust gas mass flow, a NO _x -Abgas mass flow is calculated. The fuel mass flow is calculated stoichiometrically from the exhaust gas mass flow taking into account the excess air factor. The method of DE102007042749A1 would be suitable while driving the code C0 ₂ emissions per kilometer, but it is unable to capture and document GHG emissions beyond stoichiometric combustion, such as, in particular, LCA GHG emissions generated during extraction, cultivation, land-use change, in the pre-treatment (digestion) of the feedstock, in the conversion of the feedstock, during transport and distribution of the fuel.

DE 102008005701 AI (Schmerbeck & Alberti) discloses a method for detecting the operating state of an internal combustion engine and / or for controlling the engine. The aim is to reduce the total amount of the harmful exhaust components carbon monoxide (CO), nitrogen oxide (NO _x ), carbon dioxide (C0 ₂ ) and other gaseous hydrocarbons (H _m C _n ) produced in operation, especially in conjunction with a vehicle catalytic converter. The individual pollutant emissions are weighted with specific weighting factors and combined to form a dimensionless emission number. The load-dependent pollutant ratios and the total pollutant emissions from different pollutants can be determined for certain routes. Although the method taught by Schmerbeck / Alberti is suitable for determining the stoichiometric C0 ₂ emissions per kilometer during driving, it can not store data or export it to areas outside the vehicle. Not at all, DE102008005701A1 can detect GHG emissions that arise beyond the stoichiometric oxidation in the internal combustion engine, in particular not LCA-GHG emissions that occur during extraction, cultivation, land use changes, in the pre-treatment (digestion) of the feedstock, in the Conversion of the feed, incurred during transport and distribution of the fuel.

WO2011 / 120935A1 (Nolte & Schenk) describes a method for reducing the emission of an internal combustion engine and an internal combustion engine for carrying out the method. The process includes the steps of cleaning old equipment, conditioning the fuel, reducing friction and feeding gas. Data is not collected or stored, neither fuel data nor engine data nor emissions data. Similarly, Nolte / Schenk can not export data to areas outside the vehicle. In addition, Nolte / Schenk can not detect GHG emissions that arise beyond stoichiometric oxidation in the internal combustion engine, in particular not LCA-GHG emissions generated during extraction, cultivation, land-use change, pre-treatment (digestion) of the feedstock, or Conversion of the feed, incurred during transport and distribution of the fuel.

DE102007057216B4 (Pfalzgraf) describes a system and a method for remotely starting a vehicle engine for preheating by means of vehicle heating or pre-cooling by means of air conditioning. The data transfer takes place exclusively from a remote remote control unit to the vehicle. There is no data transmission from the motor vehicle to the outside of the vehicle. Again, no data is stored, neither fuel data nor engine data nor emissions data. Similarly, Pfalzgraf can not export data to areas outside the vehicle. In addition, Pfalzgraf can not detect GHG emissions that arise beyond stoichiometric oxidation in the internal combustion engine, in particular not LCA-GHG emissions generated during extraction, cultivation, land-use change, pre-treatment (digestion) of the input material, conversion of the Feedstock, incurred during transport and distribution of the fuel.

DE102012206457A1 (Nolte & Schenk) discloses a method of reducing emissions of internal combustion engines and a vehicle having an internal combustion engine having a sensor for continuously detecting power-dependent emissions during engine operation, and a controller that caches the detected data and / or acts on the engine loading drive the internal combustion engine works up. The at least one sensor may be a C0 ₂ sensor, a particle sensor (soot particle sensor) or a NO _x sensor. The sensor or sensors have a data interface via which the sensor signal can be used as a control signal (meaning control signal) or as a measured value signal. The method may document the C0 ₂ emissions of a vehicle and provide it for further use, eg via mobile radio (GSM). The measured data of the sensors can be transmitted to an external server for emission and parameter monitoring or for external evaluation via mobile radio. The data available on the external server can be viewed via an internet browser. Status reports over certain time intervals can be displayed and a fleet can be monitored. The reduction of emissions is achieved by adding a "fuel conditioner" or an emission-reducing additive such as, in particular, hydrogen, LPG or methane gas to the internal combustion engine when certain conditions are met. "The method taught by Nolte / Schenk is suitable when driving over one to determine C0 ₂ sensor the C0 ₂ -Volumenstrom, but it is not specified that and how _two -Volumenstrom the relevant C0 ₂ -Massenstrom is determined from the stoichiometric C0. Nolte / Schenk also do not indicate that and how the C0 ₂ -Massenstrom is set in relation to a distance traveled by the vehicle route. certainly not indicate that and how the actual fuel consumption to be detected. Finally, Nolte / Schenk can not acquire GHG emissions that occur beyond the stoichiometric oxidation in the combustion engine , in particular not LCA-GHG emissions, which occur during extraction, cultivation, landnut modifications, in the pre-treatment (digestion) of the input material, in the conversion of the feedstock, in the transport and distribution of the fuel incurred.

Second, methods and apparatus for communicating electronic automotive systems with external data processing apparatus are known. It is known e.g. On-board diagnostic systems (OBD systems), which monitor relevant control devices and vehicle systems, in particular exhaust gas-influencing systems, during driving operation. Occurring errors are displayed to the driver via indicator lights and / or permanently stored in the respective control unit or in a central OBD computer of the vehicle. Error messages can then be queried in a specialist workshop via a standardized vehicle diagnostic interface (for example, the OBD2 interface).

OBD systems were introduced in California by the California Air Resources Board (California Air Resources Board) in 1988, based on the consideration that it is not enough to comply with the emissions regulations at the time of approval, but that compliance with these regulations is above the entire life of the motor vehicle must be ensured.

Originally, during the driving operation, all exhaust-gas-influencing systems were to be monitored, as well as other important control devices whose data were made accessible by their software. Any errors should be indicated to the driver via a warning light and stored permanently in the respective control unit. A specialist workshop was then able to query the error messages later via a standardized interface. The error codes (the so-called PO codes) are defined in ISO standard 15031-6.

The OBDl standard states that the self-monitoring vehicle must have its own electronic systems. These have faults that affect the exhaust gas via a light integrated into the dashboard - the so-called "Malfunction Indicator Light" - and also that the detected faults must be stored in a readable electronic data memory even require monitoring of the monitoring function, such as the monitoring of the MIL, based on the fear The diagnostic diagnostic system does not perform diagnostics regularly or for the entire life of the vehicle. Therefore, the vehicle should record when or how often the diagnoses were carried out. In addition, the new standards set specific diagnostic quotas (IUMP: In use monitor performance ratio). The results stored in the electronic data memory can be retrieved or read out via the CAN bus via a standardized socket (a serial interface with standardized protocols).

The Environmental Protection Agency (EPA) obliges all car manufacturers who want to sell motor vehicles in the US to install comprehensive OBD systems for their electric and mechanical systems from their 1996 model year in their microcontrollers (sensors) and microprocessor vehicles to monitor, in particular the engine control unit (ECU). The purpose is the identification of exhaust-active malfunctions and power losses. Most motor controllers transmit the acquired operational and diagnostic data through a standard shared electronic bus system of the vehicle, a system for communicating between multiple subscribers over a common transmission path. The bus system functions as an on-board computer network with a variety of processors that receive and transmit all data. The main computers of this bus are the Electronic Control Module (ECM) of the vehicle and the Power Control Module (PCM). While the ECM typically monitors engine control (e.g., ignition, RPM, power, exhaust gas recirculation, cruise control, etc.), the PCM typically controls the powertrain (e.g., engine, transmission, brakes). The data provided by the ECM and the PCM include vehicle speed, tank level, cooling water temperature, boost pressure, etc. In addition, the engine control unit (ECU) generates standardized diagnostic messages (Diagnostic Trouble Codes DTCs) consisting of a 5-digit code. As soon as an error message is stored in the memory of the engine control, a warning lamp, the Malefunction Indicator Light (MIL), lights up in the dashboard.

The data of the OBD system are available via a standardized serial interface. The corresponding plug contact is on the side of the vehicle from a 16-pin socket, which is usually called OBD2 socket. The pin assignment of the socket is defined and e.g. under http://www.obd-2.de/stecker-belegungen.html retrievable. The OBD socket is usually located below the dashboard in the interior of the vehicle. During a workshop visit, the OBD2 father plug of an external data scanner (service tool) is plugged into the vehicle's OBD2 socket and reads data stored in the ECM and / or PCM of the vehicle, including error messages. To do this, the engine of the vehicle is started and the data is transferred from the vehicle computers through the OBD2 socket to the data scanner. The data scanner displays the transmitted data and analyzes it. Usually, these data scanners are only used during a workshop visit or on the chassis dynamometer (dynamometer).

In practice, in addition to environmental protection and hazard prevention with the OBD, other functions will be performed, such as the prevention of further damage: With corresponding error messages emergency programs are activated to prevent further damage. After identification of a loose or broken spark plug cable, for example, the corresponding cylinder or the corresponding injection nozzle can be switched off. This prevents that unburned fuel / air mixture destroys the exhaust gas catalyst. In addition, the OBD system can also be used to simplify vehicle maintenance and anticipate repairs. The data or error messages provided by the OBD system can facilitate the search for defective components or even name them directly. However, this presupposes that the respective vehicle manufacturer discloses his service documentation for the respective error messages. There are also so-called OBD diagnostic adapters known which can be coupled via an OBD connector to the vehicle diagnostic interface (OBD socket). These OBD adapters extend the basic functionality of the OBD system, which was originally intended to store only the occurrence of certain errors. Namely, with these adapters, constantly accumulating data can be logged (stored) such as vehicle speeds, positive and negative accelerations, speeds, engine load, temperature of the cooling system, voltage of the battery, etc.

US 6611740 (Lowrey et al.) Teaches a wireless, Internet-based vehicle surveillance system based on OBD technology installed in US automobiles since 1996. A device electrically connected to a vehicle computer via cable or plug-in contact and comprising a data memory for diagnostic and operating data and a data transmission module (wireless appliance, in fact an OBD2 adapter) records operating data similar to the data scanners in service workshops at the OBD2. Socket and transmits the diagnostic and operational data of the vehicle while driving quasi-real-time via a communication network to a central host computer system. The host system receives the diagnostic and operational data of the vehicle from the communications network and processes it into vehicle diagnostic records. In addition, the host system hosts an Internet web site that displays these vehicle diagnostic records. Finally, the host is able to transfer data and work instructions via the communications network to the in-vehicle "wireless appliance." Accordingly, the "wireless appliance" (the OBD2 adapter) is capable of receiving and processing these data and work instructions. A software program that controls and controls the communication between the wireless appliance and the vehicle's OBD2 system determines which diagnostic and operating data should be collected from the vehicle computer with which frequency the storage unit of the "wireless appliance" stores data and also at what time or at which frequency the stored data the data transmission module transmits a data packet to the host system. Diagnostic and operational data may include DTCs, vehicle speed, tank level, injection pressure, range, engine speed, distance, oil pressure, oil temperature, tire inflation pressure, tire temperature, coolant temperature, air boost, engine power, adjustment parameters, alarm status, Accelerometer status, cruise control status, fuel injection performance, ignition timing, ABS system status. The purpose of this system is to monitor the data in the vehicle. There is neither a calculation of the vehicle data nor a conversion. Neither fuel consumption nor vehicle emissions are considered. Certainly not GHG emissions are considered.

US 6832141 (Skeen et al.) Also teaches such an OBD adapter. The adapter, which is also referred to as an OBD module or "onboard diagnostic port memory module", has a) a connection with the OBD2 socket of a vehicle, b) a data memory for the retrievable storage of data, c) a battery for the supply of an electronic D) an electronic clock for time stamping the data received from the OBD2 system, e) a microprocessor for processing both data received by the adapter from the OBD2 system and data received from the OBD2 system F) a program memory stored in operation with the microprocessor for storing work instruction / program software, this work instruction relating to the storage of the vehicle operating data in the data memory as well as the output of this operating data The OPD2 adapter is connected to a PC, which programs it with work instructions that determine, among other things, which OBD2 data Has to save adapters. Afterwards, the OBD2 adapter will be vehicle on the 0BD2-Buch.se plugged. The data is logged / logged per trip, with the starting of the engine defining the start of the run and the engine being turned off. After one or more trips, the OBD2 adapter is uncoupled from the OBD2 socket of the vehicle and connected to a PC that is capable of using intelligent software data queries and data evaluations. The focus is on finding strong acceleration, heavy deceleration, vehicle speed, driving distances and the parameters required to be recorded by the Society of Automotive Engineers SAE. Essentially, the OBD2 adapter of US6832141 has the purpose of recording individual driving behavior of drivers and facilitating the performance of repairs. US6832141 teaches neither the recording of the tank levels nor the recording of the consumed fuel quantities nor the recording or calculation of GHG emissions, let alone the recording of the LCA-GHG emission quantities. Also, no data is passed through a communication network to a central office or to a back-end. Although data transmission may be via an optional infrared interface of the adapter, this requires an optical connection between the adapter and the data sensing device. Data transfer via Bluetooth does not take place.

US2008 / 0015748A1 (Nagy) discloses a system and method for displaying and analyzing vehicle diagnostic data. Et al For example, this system includes a vehicle interface module (VIM) capable of reading in-vehicle vehicle operation data and sending commands to at least one electronic vehicle component via a local area network (LAN) and operating data as well as position data WAN (Wide Area Network) to send and receive. The VIM adapter is further connected to a control and monitoring application and via an air interface (wireless) with a navigation device (positioning system). The VIM adapter, which is equipped with a microcontroller, a data memory and a Bluetooth chip, is wirelessly connected via an air interface to a mobile user-communication terminal (hand-held or vehicle-mounted device) and this via the Internet or mobile radio to a web server. The mobile user communications terminal (which may be a smartphone) has a dynamically configurable software application and API (Application Programming Interface). In addition to the vehicle operating data, GPS position data are also transmitted to the mobile user communications terminal (smartphone). The operating data of the vehicle can be forwarded to a web server via a wide area network (Internet). Thus, the transmitted data can be viewed by end users or software applications can more or less automatically gain access to such data. The analysis and display of the operating data of the vehicle takes place on the user communication terminal, which may be a smartphone. US 2008/0015748 A1 does not disclose an investigation of vehicle and route specific fuel consumption nor a determination of vehicle and route specific GHG emissions. Not at all, US 2008 / 0015748A1 describes the vehicle and route-specific determination of LCA-GHG emissions.

Since 2001, compulsory and open vehicle diagnostic systems for European motor vehicles have also provided unspecified exhaust gas data in addition to the OBD2 data required by the EPO. Thus, the (unspecified) exhaust gas data are basically available to the data transmission devices located in the vehicle. These can thus be transmitted via a mobile network or via the Internet to an unspecified back-end (data center).

US20100256861 (Hodges) describes a system and method for performing vehicle diagnostics. The system consisting of a vehicle monitoring computer system and a mobile phone serves to monitor a vehicle. It can provide diagnostic information of a Receive vehicle, with respect to certain parameters thresholds can be set. Once at least one of these thresholds is exceeded, the computerized vehicle monitoring system automatically sends a text message to the mobile phone. In this text message, a vehicle identification number or a mobile identification number (PIN) can be integrated. In this transmission of vehicle diagnostic data, the vehicle is wirelessly connected to the system. It can transmit vehicle diagnosis data via a communication network (mobile radio network) to another communication network (Internet). The data transmitted in this way can be used or evaluated by arbitrary bodies (driver, vehicle owner, mobile phone user, fleet manager, insurance company, leasing company, security service and other agencies). Such diagnostic links are limited to the unidirectional transmission of vehicle diagnostic data from the vehicle to the (mobile) user communications terminal. This means that only vehicle diagnostic data can be evaluated. The US 2010 0256861 describes neither a determination of vehicle and route-specific fuel consumption nor a determination of vehicle and route-specific GHG emissions. Not at all US20100256861 teaches the vehicle and route-specific determination of LCA-GHG emissions, for which the system of US20100256861 would not even suitable.

US 6732032 (BANET et al.) Teaches a method and apparatus for detecting certain vehicle exhaust gases. The method comprises 4 steps, 1) the generation of exhaust gas data using at least one on-vehicle microcontroller (sensor), 2) transmission of the exhaust gas data via an OBD interface to a module (adapter), the microprocessor, a 3.) transmitting the data via this transmitter and a wireless communication system to a host computer; 4.) analyzing the transmitted data to determine the vehicle-specific emission power. As emission data Banet et al. harmful gaseous hydrocarbons, nitrogen oxides, carbon monoxide or their derivatives. Carbon dioxide is not recorded as an emission. The data analysis takes place in the host system. It contains the selection of the data relevant for the calculation of the exhaust gas emissions, their storage in the host system or in the database of the host system and the use of algorithms for the approximate determination or prediction of the "emissions" Due to the centralization of the data analysis in the host system, software can be easily modified if necessary Banet et al. Derive the exhaust gas data mainly from data from the lambda probes (0 ₂ sensors) installed in the exhaust system of the vehicle This mathematical model processes the input numerical values so that emission / pollution concentrations can be predicted The predicted emission / pollution concentrations are compared with the limits published by environmental organizations to determine whether or not the vehicle meets the given emission standard , The determination of the exhaust emissions taught by the US 6732032 does not include the function of the route-specific determination of the fuel consumption or energy consumption actually incurred during everyday vehicle use. They also do not include the route-specific determination of the emissions of a motor vehicle. The analyzed exhaust gases are based solely on the 0 ₂ values supplied by the lambda probes. C0 ₂ values are not measured nor calculated. Neither (LCA) GHG emission values are determined, nor are route-specific (LCA) GHG emissions determined.

US 6988033 (Lowrey et al.) Describes a method and apparatus for vehicle specific fuel efficiency determination. Since most engine controls (ECU) do not calculate fuel efficiency, Lowrey et al. Data from which fuel efficiency can be calculated. The procedure consists of 4 steps: 1.) Detecting an off-vehicle Speed, mileage calculation, engine speed, engine power, air mass flow existing record, 2.) transmission of the data set to a "wireless appliance" comprising a microprocessor and a transmitter with air interface, 3.) transmission of the data set or a modified form of the Data record with the transmitter of the "wireless appliance" via an air interface to a host computer system; and 4.) analysis of the data record in the host computer system in order to determine the fuel efficiency of the vehicle. The air mass flow forms the basis for the calculations, ie, the fuel consumption and thus the fuel efficiency are not measured directly, but derived calculatory from other data. In addition to deriving the air mass flow from stoichiometric standard ratios, which can be effectively volatile, this method also accepts an error rate of +/- 10% in terms of gasoline density. The derived consumption values are therefore not very precise with an error bandwidth of 20%. In addition, this method and the corresponding devices are only suitable for calculating the fuel efficiency of gasoline engines. The determination of the fuel efficiency of diesel vehicles and of motor vehicles with fuel cells or electric motors is not possible. C0 ₂ values are not measured nor calculated. Neither (LCA) GHG emission values are determined, nor are route-specific (LCA) GHG emissions determined.

US 6928348 (Lightner et al.) Teaches a method and apparatus for remotely detecting vehicle emissions. This comprises 4 steps: 1.) acquisition of a vehicle-specific data record, which comprises an error message, the status of the fault indicator light MIL or data relating to up to 8 of the so-called "I / M"statuses; a "wireless appliance" that has a microprocessor and an air interface transmitter. 3.) sending the dataset or a modified form of the dataset to the transmitter of the "wireless appliance" via an air interface to a host computer system and 4.) analyzing the dataset in the host computer system to predict if the vehicle is using its specific emissions exceed or fall below the prescribed limits The collection, transmission, transmission and analysis of the data is repeated in order to keep the emission levels of the vehicles up to date The procedure involves communicating the results of the investigations to the vehicle owner 8 I / M status involves determining whether one or more occurrences have occurred: i) misfiring, ii) faults in the power supply, iii) faults in one of the monitored vehicle subsystems, iv) malfunction of the catalytic converter, v) Faults in the carburettor, vi) malfunction of one of the lambda probes, vii) faulty heating of one of the lambda probes, viii) fault in the exhaust gas srückführungssystem. Thus, the "determination of vehicle emissions" consists only in forwarding the error messages generated by the vehicle.Neither Lightner et al., Exhaust gas volumes, exhaust gas masses and pollutant contents nor calculate these exhaust gas values.C0 ₂ values are not measured Neither (LCA) GHG emissions nor NDT (LCA) GHG emissions are determined.

The DE102011076638A1 (Kaufmann) discloses an improved method for vehicle communication, a so-called interface module (OBD adapter) and a diagnostic and control network for a variety of vehicles. Data from an in-vehicle open vehicle diagnostic system (the OBD2 system) is also transferred to an adapter from the open (OBD) interface of the vehicle diagnostic system via an OBD adapter plugged into the OBD interface and having an air interface This air interface is first transmitted to a mobile user communications terminal (smartphone) and from there via a suitable communication network (mobile radio, Internet) to a data network system. The transmitted data from the vehicle diagnostic system are supplemented by additional data (additional data) obtained outside the vehicle diagnostic system. The data network system transmits the added to external additional data vehicle diagnostic data back to the mobile user communication terminal (smartphone) and / or to the OBD adapter. At least one instruction instruction (computer program, app) is used, which is compatible with the mobile user communications terminal (smartphone).

The additional data generated externally by the vehicle diagnostic system may consist of the geographical position, the time of day, the state of motion, the local environment (vehicle interior), the acoustic environment, the temperature and the humidity. They can be obtained from add-on modules of the mobile user communications terminal (smartphone), from the communication network, from the data network system or from external sensors. The optionally supplemented with external additional data vehicle diagnostic data can be transmitted from the mobile user communication terminal (smartphone), which is assigned to a first vehicle via air interface to air interfaces of second and third vehicles and thus to other mobile user communications terminals (smartphones), the second and third vehicles are respectively assigned. The driving situation resulting from the vehicle diagnostic data and additional data can be determined continuously and / or in real time. Vehicle control functions may be changed based on preset limits (driving situations) with and without driver verification.

On the basis of the vehicle diagnostic data supplemented with external additional data, "instruction instructions" (software programs) integrated in software applications can perform one or more of the following functions: vehicle control proposal, vehicle repair notification, accident assessment, accident notification, route setting, route analysis, travel route costing compensation, driver compensation, vehicle passport data update, vehicle passport data storage, driving behavior analysis, driving behavior control.

In this case, an interface module (adapter, dongle) attached to the vehicle diagnostic interface (OBD2, SAE) takes over data from the vehicle diagnostic system, stores these and, if necessary, supplements them with adapter-internal and / or adapter-external additional data. The OBD2 adapter (the interface module) thus has memory and logic. The logic of the OBD2 adapter may execute "instruction instructions" that are compatible with the mobile user communications terminal (smartphone) .The OBD2 adapter further includes a first antenna for bidirectional wireless communication with communication networks (WiFi, Bluetooth, LAN, WLAN, or the like). and a second antenna for performing a unidirectional broadcasting function.

Kaufmann also teaches a diagnostic and control network that retransmits vehicle diagnostic data supplemented with external data to the mobile user communications terminal and / or the vehicle diagnostic interface for a variety of vehicles equipped with OBD2 adapters and mobile user communications terminal (smartphone). At least one instruction instruction (computer program, app) is used, which is compatible with the mobile user communications terminal (smartphone). The data link system may include a database and attached proprietary data systems. The "instruction instructions" can be stored on the mobile user communications terminal (smartphone) or on the data network system.The mobile user communications terminal (smartphone) can be designed to obtain additional data from an external sensor or an internal additional module. Module, a clock, a motion module, a gyroscope, a camera, a video camera, a microphone, a speaker or a light surface. As already described in US2008 / 0015748A1, the method and the system of DE102011076638A1 can provide unspecified exhaust gas data from the open vehicle diagnostic systems of the motor vehicles via the OBD2 interface and a transmitable OBD2 adapter as well as a smartphone via mobile radio or Internet into an unspecified data network system transfer. The unspecified exhaust gas data can be supplemented with additional data such as the global geographical position (GPS). As part of a special "instruction rule" can be given a "particularly reduced C0 ₂ consumption", where neither of these "reduced C0 ₂ consumption" even the way how this is to be achieved is specified in detail.

The instructions for instruction taught by Kaufmann do not include the function of determining the actual fuel consumption or use of energy in everyday vehicle use, nor do they include the route-specific determination of the emissions of a motor vehicle, let alone the determination of route-specific (LCA) -) GHG emissions Neither does Kaufmann indicate in this publication that such values should be determined, nor does it indicate in which manner or by what means these values are determined.

Finally, US 9224249 (Lowrey et al.) Claims patent protection for a method and system in which an adapter capable of wireless near-communication and mechanically / electrically connected to a communication interface of a vehicle ("Short Range Wireless Device ") and an additional device (" Access Device "), which may be a smartphone, a wireless local communication link is established. The patented method further includes the additional device polling vehicle information via this wireless proximity link from the vehicle and the additional device receiving this information via this wireless near link. Finally, the method involves the transmission of this vehicle data by the "access device" via a wireless communication network to at least one internet-accessible web site, with the exception that in US 9224249 the information transfer is triggered by the "access device" and not by The "Short Range Wireless Device", this patent describes neither the function of the route-specific determination of the actual fuel consumption in everyday life nor the determination of energy use.They also do not include the route specific determination of the emissions of a motor vehicle, and certainly not the determination route specific (LCA) GHG emissions: Lowrey et al., Neither states that such values are to be determined, nor does it indicate how or by what means these values are determined.

Thirdly, there are known methods and devices for the detection and processing of information in the field of traffic, with the help of which government agencies and independent institutes come to the latest statements concerning traffic and / or to trend and scenario calculations.

For example, the German Federal Environment Agency has to develop the computer program TREMOD (Transport Emission Model). TREMOD is the expert model used by the Federal Environmental Agency, the German Federal Ministries, the German Automobile Industry Association (VDA) and Deutsche Bahn AG to calculate air pollutants and greenhouse gas emissions from motorized traffic in Germany. With the help of this model, trend and scenario calculations for the period from 1960 to 2030 are possible.

In TREMOD all types of passenger transport operated in Germany (cars, motorized two-wheelers, buses, trains, aircraft) and goods traffic types (trucks, trains, ships) are from the base year Recorded in 1960 in annual steps until the year 2030. The basic data ranges from driving, transport and utilization rates to specific energy inputs and emission factors. The calculation of the levels of pollutants released in road traffic is based on the emission factors in the Emissions Factors Handbook (HBEFA). Emissions include nitrogen oxides, hydrocarbons differentiated according to methane and non-methane hydrocarbons as well as benzene, carbon monoxide, particles (fine dust), ammonia, di-nitrous oxide (nitrous oxide), carbon dioxide and sulfur dioxide. Both the direct emissions including the evaporative emissions and the emissions that occur in the process chain upstream of the energy input are accounted for.

The HBEFA data used by TREMOD are determined by ERMES (see above). Like the ERMES has admitted in its letter "diesel light duty vehicle NO _x emission factors" from 09 October 2015 soft the previously determined "emission factors" despite adjustment of driving cycles increasingly from the resultant in the real world emissions from (so ). It follows that the HBEFA data are also incorrect. Since TREMOD is based on HBEFA data, the expert model TREMOD also calculates and simulates incorrect emission values - ie, far too low. Accordingly, the results obtained with TREMOD are not correct as long as the emission levels provided by ERMES do not match the emission levels generated in reality.

In summary, it can be stated that, despite the mobile technology, vehicle diagnostic systems, vehicle communication systems, simulation models and algorithms achieved on the on-board systems without mobile, specially installed and expensive testing technology, it is not yet possible with the current state of the art In everyday use, actually arising fuel consumption (electricity consumption) and emissions (greenhouse gases, nitrogen oxides, nitrous oxide, particulate matter) of individual motor vehicles causally and correctly capture, map and transfer to external sites, especially not for a variety of individual vehicles and certainly not in a ( extended) LCA consideration. Also the values obtained by automobile manufacturers and ERMES on chassis dynamometers (and partly manipulated) for fuel consumption. Energy use and emissions continue to be inconsistent with the levels of fuel consumption and emissions that drivers and car owners actually achieve in everyday practical use. For road vehicles, therefore, there is still a significant discrepancy between the published official and the fuel consumption, energy input and emission values actually generated in everyday use.

task

The object of the invention is therefore to improve existing methods and systems for determining fuel consumption, energy consumption and emissions of road vehicles in such a way that they capture the real values that are actually incurred in everyday operation and map them closer to reality.

solution

The inventive task is solved with respect to the method by the method disclosed in independent claim 1 and with respect to the devices by the system disclosed in independent claim 56. Advantageous developments of the invention will become apparent from the dependent claims. The invention is based, in part, on previously known disclosures, the disclosure contents of which are expressly incorporated into the method and the system according to the invention. However, none of these disclosures is directed to detecting actual fuel consumption, actual energy use or actual GHG emissions of individual automobiles in day-to-day operation. In addition, the systems and devices known from the prior art disclosures are not suitable for detecting the life cycle emissions of road vehicles.

Summary of the invention

The inventor has achieved the object by proposing a method in which vehicle operating data of a road vehicle obtained during driving are detected by a so-called front end and, using a switching device that can be a smartphone, via a communication network that is a mobile radio network or the Internet may be transmitted to a so-called back-end, which is a server or a data center. According to the invention, at least two files or databases are maintained in the backend, a file / database with vehicle-specific data - the vehicle file / database - and a file / database with fuel-specific data - the fuel file / database , The front-end transmits the data either directly to a communication network or indirectly first to a switching device, which forwards it via a communication network to the back-end. The vehicle-specific data transmitted directly or indirectly to the back-end and stored in the vehicle file includes, among others: Details of the route-specific fuel consumption or, in the case of electricity, information on the use of energy. That is, these data include both the distance traveled and the resulting fuel consumption (which can also be a power consumption).

The fuel file / database in the backend, which can also be a stream file / database, also contains information on the energy content or calorific values of the individual fuel types. By multiplying the fuel consumption quantities with the respective calorific values, the individual energy inputs result. Their knowledge is relevant for comparisons of different fuels.

In addition, the fuel file / database contains information on the GHG emissions of the various main fuel types and / or fuel sub-types, which vary depending on the source of the raw materials used and on the manufacturing process. Due to the reference to the energy content, more precisely: due to the reference to the lower calorific value of the fuels, the GHG emissions of various fuels are comparable.

The fuel file / database carried in the back-end preferably contains information on the GHG emission of the various main fuel types and / or fuel sub-types, and particularly preferably information on the energy-specific (LCA) GHG emission. The absolute and relative GHG emissions can be calculated both from the specific GHG emission values related to the unit of sale (liters, kilograms, kilowatt hours) of the fuels and from the specific GHG emission values related to the unit of energy (MJ, kWh), where the latter are more accurate.

The covered by a motor vehicle route is detected by the (electronic) odometer (alternatively by a vehicle-external GPS module), continuously transmitted to the vehicle diagnostic system and stored there if necessary. At the interface of the vehicle diagnostic system, which is preferably a standardized OBD2 interface, these data are usually available for reading at any time. The front-end (the OBD adapter) reads the route data (or it receives it from a vehicle-external GPS module) and stores it. In particular, the front end stores the (since start-up) odometer reading from when refueling of the motor vehicle takes place. The back-end calculates later from the various refueling odometer readings the distance that the vehicle traveled between refueling. This route can also be determined in other ways.

Furthermore, the back end receives from the front-end directly or indirectly via switching equipment (smartphone) and communication network (Internet, mobile or the like) the information as to which main fuel type the motor vehicle consumed on this route. This is relatively simple for monovalent motor vehicles that have only one drive technology: gasoline vehicles consume gasoline or petrol, diesel vehicles diesel fuel, CNG CNG vehicles, LPG vehicles LPG, hydrogen fuel cell vehicles and electric vehicles electric power , For CNG, hydride, dual-fuel and electric vehicles with so-called range extenders i.d.R. two types of fuel are detected and corresponding data is transmitted.

In addition, the back-end of the vehicle diagnostic system receives either directly via the front-end and communication network or indirectly via the front-end, smartphone and communication network, the information of what quantities of fuel consumed the motor vehicle on the route, which is preferably the route, the motor vehicle has traveled between two refueling (alternatively, the front-end or the switch receives the information from vehicle-external sensors or the switch by manual input). In the back-end, it is calculated with reference to the fuel file from the amount of fuel consumed, the amount of energy consumed by the motor vehicle between two refueling (namely, in the fuel file is deposited, which energy content, more precisely: which lower calorific value, the individual fuel ). Electricity is treated like fuel.

A special evaluation program of the back-end (algorithm) calculates from the traveled route of the motor vehicle, the types of fuel used by the motor vehicle on this route, the route-specific amounts of energy used and the fuel-specific (LCA) greenhouse gas emission values (LCA). ) GHG emission quantities, (LCA) GHG emission volumes or (LCA) GHG emission masses the motor vehicle has emitted on the route traveled into the environment (earth's atmosphere). Accordingly, of course, the corresponding (stoichiometric) GHG emission levels can be calculated. Finally, the (LCA) GHG emission values can also be calculated directly from the fuel consumption if the emission values per fuel sales unit are available.

During the evaluation, the determined route-specific fuel consumption quantities or the consumed energy quantities of the considered road vehicle are converted into other vehicle-specific quota values, eg the fuel consumption per 100 km, the fuel consumption per km, the energy use of one year, the (LCA) emission quantity in GC0 ₂ equivalent per km, the (LCA) GHG emission rate in GC0 ₂ equivalent per 100 km, the C0 ₂ - emissions in one day, one week, one month, one year or over the entire vehicle use time, etc., etc. ,

The calculation results of the back-end can be viewed by at least one user, are available for at least one software application (software program), can be printed out as a list, are transmitted via the communication network (eg Internet) to interested parties or made available to them or be used in any other way. The system used to carry out the method according to the invention consists essentially of vehicle sensors (eg tank level sensor) or of vehicle systems (eg engine control) which transmit specific data to the on-board diagnostic (OBD) system of the vehicle from the vehicle's OBD system, and also from a front-end, a switch, a communication system, and a back-end.

The front-end, which may be an interface module (VIM), transmitter, adapter, dongle, computer system or the like and is preferably an OBD2 adapter, is connected to at least one electronic component of a vehicle, preferably with the on-board vehicle diagnostic system of the vehicle, which continuously provides operating data via a so-called OBD2 interface. These data are in the method according to the invention u.a. around the odometer reading, the tank level and in electric and so-called hydride vehicles, which have at least two drive technologies of which one is usually an electric drive, possibly also to the state of charge of the battery.

The front-end or the OBD2 adapter preferably comprises an OBD connector (particularly preferably an OBD2 connector), a microprocessor, a program memory, a data memory and a Bluetooth chip. Ideally, the OBD2 adapter additionally has a mobile radio modem / transmitter, a mobile radio antenna (external antenna or embedded in a printed circuit board / circuit board or embedded in a housing of the cellular modem / transmitter), a mobile radio receiver , a WiFi / WLAN interface, an interface for memory expansion, a receiver and / or an evaluation unit for global positioning data (eg NAVSTA-GPS, GLONASS, GALILEO, BEIDOU) and a rechargeable battery (rechargeable battery). The implementation of the method is also possible with front ends whose technical structure is kept simpler.

The OBD2 adapter is plugged into the OBD2 socket or the OBD2 interface of a vehicle, which is i.d.R. located in the vehicle interior near the fuse box. By attaching it is directly connected to the on-board diagnostic (OBD) system of the vehicle. This also indirectly links it to the vehicle's sensors and systems, which provide measurement results and data electronically to the OBD system. Typically, these sensors and systems include odometer and tank sensors that measure the level of the at least one tank. The OBD adapter and its OBD connector may also have a different standard, e.g. an OBD3, an OBD4 or any other OBD standard. The data of the tank sensors and the odometer may also be provided by other sensors or systems, e.g. by external sensors and systems.

According to the invention, after registering the customer or the vehicle, a special app is downloaded to a smartphone (see below). After the download, the smartphone user initiates contact with the front-end or OBD2 adapter. The front-end is preferably loaded and initialised by this smartphone via Bluetooth or WiFi / WLAN with a software application (adapter app). This adapter app uses a special programmed instruction manual to ensure that the OBD2 adapter records at least the odometer reading of the road vehicle (or the distance traveled by the road vehicle between two fueling operations) and the fueling data (tank level at the start of refueling, tank level at Termination of refueling and / or capacity and in electric and so-called hydride vehicles, which have at least 2 drive technologies, one of which is usually an electric drive, the state of charge of the battery at the start of charging and the state of charge at the completion of charging and / or the amount of electricity charged). Preferably, the OBD2 adapter stores the collected data. From now on the OBD2 adapter communicates with the smartphone with which the initialization was performed, and delivers that data when needed, id. via Bluetooth or WiFi / WLAN (but other ways of interacting are possible as well, such as sending the data from the mobile-enabled front-end via a mobile network to the back-end).

The switch, which is preferably a smartphone (see above), may receive, after downloading a special app to the front-end, that data via a suitable interface and using an appropriate protocol (cable, preferably Bluetooth, WiFi / WLAN or the like) , Due to a special software application (software program or app), the switching device or the smartphone is able to store this data with and without buffering and with and without the addition of additional data (such as GPS data) over an existing software Communication network (Internet, telephone network, mobile network, cable network or the like), preferably via the Internet, forward to a back-end (server with a suitable software application, web server, database, data center with appropriate software, data network system, user terminal / PC with appropriate Software application or same).

In the back-end, which can consist of a multiplicity of computers, programs and files and is usually a server system with suitable software programs or also a web server, a database, a data center with suitable software, a data combination system, a user terminal with a suitable software application or the same), data, preferably vehicle-specific data, in particular data on a distance covered by the vehicle and data on refueling of the motor vehicle, are received via a suitable interface from the communication network and before or after a calculation or evaluation stored in at least one vehicle-specific file or database (vehicle file, vehicle database) stored and kept retrievable for further analysis or calculations.

Furthermore, at least one file or database with fuel-specific data (fuel file, fuel database) is kept in the back-end. Here are the different technical characteristics of the various fuels (fuel main types and fuel subspecies) stored retrievable. In particular, the different energy contents or calorific values of the individual fuels are stored, as average values for main fuel types. The energy contents or calorific values of the various fuel sub-types are preferably also stored here. Furthermore, the (LCA) GHG emission values of the individual main fuel types and / or fuel sub-types are stored and retrievable (optionally, the stoichiometric GHG emission values can also be kept retrievable here). The main fuel types and / or fuel subtypes are used both for raw materials used (eg crude oil of different origin and different recovery methods) and also for production processes used (eg conversion of cereal grain into ethanol using natural gas energy and conversion of cereal grain into ethanol of brown coal energy). Examples of the large number of fuel sub-types are the EU Directives 2009/28 / EC and 2015/652 / EC. The (LCA) GHG emission values preferably relate to the individual energy unit or the (lower) calorific value (eg MJ or kWh _Hi ).

In the back-end, a special evaluation program (algorithm) evaluates in a first step the vehicle-specific data on fuel consumption (power consumption) transmitted from the communication network. Preferably, this evaluation program calculates from these data the route-specific energy input of at least one motor vehicle by multiplying the fuel consumption with the corresponding fuel-specific heating value Hi (alternatively, it calculates these energy inputs from other vehicle-specific data transmitted to the back end).

In a second step, the evaluation program calculates from the route-specific energy input using the fuel-specific (including stream-type-specific) data of the fuel file or the fuel database, preferably with the aid of the different energy-specific (on energy unit related) (LCA) GHG emission values of the fuels or stream type, the route-specific (LCA) GHG emission quantities or the (LCA) GHG emission volumes and / or the (LCA) GHG emission masses that emitted the motor vehicle into the environment (earth's atmosphere).

Preferably, the determined route-specific energy input and / or (LCA) GHG emission quantities of the considered road vehicle are converted in a third step into other vehicle-specific quota values, for example, the usual fuel consumption per 100 km, the energy input of a year, the usual (LCA) GHG emission level in gC0 ₂ equivalent per km, C0 ₂ emissions per month or other common quota values.

According to the invention, the vehicle-specific calculation results of the back-end or aggregated values for at least one user can be viewed and / or made available for at least one software application (software program). They may also be printed out as a list, transmitted to interested parties via the communications network (e.g., Internet), made available to the general public, or otherwise made available.

Thus, it is now possible without specially installed and complex mobile testing technology, the actual consumption of fuel (electricity consumption) and GHG emissions causally and correctly capture, map and transfer to external sites, especially in the context of an (extended) LCA consideration , In road vehicles, there are thus no longer any significant discrepancies between the published (official) and the actual fuel consumption and GHG emission values in everyday use.

Detailed description of the invention, developments and embodiments

In the following, embodiments will be described. With regard to the additions to the inventive teaching, the applicant refers to the relevant prior art. It should be noted that both the basic idea of the invention and the embodiments can be modified and changed in many ways, without departing from the basic idea and the basis of the invention. For obvious modifications, changes and additions to the invention, therefore patent protection is also claimed.

The features of the invention disclosed in the description, the drawings and the claims may be essential for the development of the invention either individually or in any combination with one another.

The basic idea of the invention should not be limited to the exact shapes or the details of the embodiments shown and described below. It should also not be limited to an article that would be limited in comparison to the subject matter described in the claims. At specified design limits, values within the limits are also to be disclosed as limit values and may be used and claimed as desired.

Relevant features, advantages and details of the invention will become apparent from the following detailed description of individual embodiments. In a first section that will be The method according to the invention and further developments of the method and in a second section the system according to the invention and further developments of the system.

The basic embodiment of the method and system described above in the summary can be advantageously modified to various design variants in many ways. A very simple embodiment of the method and system according to the invention is a method and a system in which the transmission of the collected vehicle-specific data from the front-end to the back-end does not take place via a Bluetooth, WiFi / WLAN or mobile radio network. Interface of the front-end, but rather via the OBD2 connector of the front-end. This can be done so that the front end after a certain distance (drive, 100 km, 1,000 km, 5,000 km, 10,000 km, 20,000 km, 50,000 km, 100,000 km) or time (day, week, month, quarter, year etc.) or event-related (workshop visit of the vehicle, expiry of a test interval, TÜV appointment, etc.) deducted from the OBD2 socket of the vehicle and plugged into a socket that is connected to a device or facility combination that is suitable is to read the vehicle-specific data stored in the front-end or a version thereof and forward it to the back-end.

Such a device may e.g. an external vehicle diagnostic device that is connected to the Internet and that transmits the data read from the front-end or a version thereof via the Internet to the back-end. Such a device may also be a PC or another communication terminal (laptop, tablet, smartphone, server or the like) to which such a socket is connected. The external vehicle diagnostic device, the PC or the other communication terminal may be connected to a communication network other than the Internet (cable network, telephone landline, mobile network, intranet, data link system or the like) and the data read from the front-end or transfer a version of it to the backend via this other communication network.

For example, it may be possible for the front end to be disconnected from the OBD2 mother socket of the vehicle after one quarter and plugged into another OBD2 mother socket connected to a PC which in turn is connected to the Internet. The front-end (the OBD2 adapter) has an internal power supply, which ensures that no loss of data by disconnecting from the OBD2 socket of the vehicle occurs (namely, the power is supplied via the PIN 16). The prevention of data loss is also possible through front-end internal storage on a medium or module (e.g., a flash SSD) whose storage capacity is independent of a constant power supply to the front-end. The PC has software that is capable of communicating with the front-end and reading out data from the front-end, possibly also performing data analysis. The data read from the front-end or a version thereof is transmitted from the PC via the Internet to the back-end. Instead of a PC, an external vehicle diagnostic device / system or another communication terminal can also be used (see above).

In this very simple embodiment, the structure of the front-end can be kept simple, which has technical and economic advantages. It is then mainly a data store. However, this simple front end may also include a GPS module and / or an electronic clock. The GPS module provides the GPS coordinates that may be required, and the clock the time for the electronic time stamp used to provide the captured vehicle-specific data.

An advantageous development of the basic embodiment of the method and system described in the summary is given if the individual motor vehicle clearly is identifiable. This is the case when the motor vehicle receives a unique identification number, which can be both numeric and alphanumeric. This identification number is preferably stored in the vehicle file / database. It may, but need not, be the same as the front-end identification number and / or the intermediary's identification number. It can also be identical to the vehicle ID number assigned by the car manufacturer. This identification number is added to the records provided by the front-end so that records flowing into the back-end can be uniquely assigned to a vehicle from this and correspondingly stored in the vehicle file / database.

In addition, it is advantageous if the front end is clearly identifiable. This is e.g. given if it receives a unique identification number, which can be both numeric and alphanumeric. This identification number is preferably also stored in the vehicle file / database. It may, but need not be, identical to the identification number of the motor vehicle and / or the identification number of the switching device. It can also be identical to the ID number given by the manufacturer of the front-end.

Furthermore, it is advantageous if the switching device is uniquely identifiable. This is e.g. given a unique identification number, which may be both numeric and alphanumeric. Preferably, the identification number of the switch consists of the telephone number under which the switch is to be reached. This identification number is preferably also stored in the vehicle file / database. It may, but need not, be identical to the identification number of the front-end and / or the identification number of the motor vehicle. It can also be identical to the ID number assigned by the manufacturer of the switching device.

By the unique identification of the motor vehicle, the front-end or the switching device, for example, an access authorization can be checked. Only uniquely identified devices are then allowed to communicate with each other or may receive and / or transmit data. For example, prevents unauthorized persons from accessing data from the system. Further advantages result from the state of the art.

In general, neither the (commercial) front-end nor the (commercial) switching device have the ability or function odometer readings during refueling, traversed between two refueling routes, information on the types of fuel tanked, tank levels and / or fuel quantities recorded and to transfer to a specific backend. Certainly not have (commercially available) front-ends or the (commercial) switching equipment on the ability or function, odometer readings during recharges, between two charges covered routes, battery charge states, charged current types and charged amounts of electricity to a particular back-end transferred to. This requires special investigative procedures (algorithms) that can be translated into software applications or programs. The inventive method provides for the use of such an algorithm and the inventive system comprises such an algorithm.

In order to make the procedure possible, a special software application (software program, app) is created and made available at a central location (eg Google Play or the Apple Store). Users download the special app via communication network (Internet, mobile or the like) from one of these platforms on their smartphone (switching device) down. It is also possible to transfer the special app via hardware (eg USB stick, CD or the like) to the switching device. It goes without saying that the spe- pull software application (App), which empowers the switching device to take over the functions provided by the method or system according to the invention may already have been transferred from the manufacturer to the switching device, the switching device is thus already supplied with this special software application from the manufacturer ,

After downloading the special app on the switching device, which is preferably a smartphone, after registration of the vehicle and / or the front-end, which is preferably an OBD2 adapter with a microprocessor and a program memory, a special SubRoutine (work instruction ) of the new smartphone app that allows the smartphone to connect to the OBD2 adapter plugged into the OBD interface (which is powered by it). If the front-end or the OBD2 adapter has not already been equipped by the manufacturer with a special adapter software (adapter app), the smartphone transmits this special adapter software preferably via the air interface (eg Bluetooth or WiFi / WLAN) to the Front-end (OBD2 adapter), more specifically in the program memory of the front-end (for further details, refer to the state of the art). The front end is initialized with it.

After initialization, the user registers himself, the front-end and his vehicle in the back-end. This can be done via the switching device (smartphone) or over the Internet (which requires the presence of an Internet-enabled user communication terminal). By registering, the user ensures that the records transmitted to the backend are not lost, because usually the backend processes only records of known vehicles.

At the latest after registration, the front-end is capable of operating data of the vehicle, in particular odometer readings, between two refueling (charges) covered routes, information on the types of fuel (types of fuel), tank levels (battery charge) and / or fuel quantities (charged Electricity quantities) to capture, store, provided with a time stamp and directly via the communication network to the back-end or indirectly first to the switching device and then to transfer via the communication network to the back-end.

At the interface of the vehicle diagnostic system, which is preferably a standardized OBD2 interface and as well as the front-end or the OBD2 adapter has a standardized OBD2 plug contact, are usually current operating data of the various vehicle systems (engine control, tank sensor , Odometer, etc. etc.) available for reading at any time. This feature is used by data scanners when the vehicle is checked in stand or on chassis dynamometers. Provided with the special front-end software (the adapter software program), the front-end or the OBD2 adapter can read the operating data while driving, with an electronic date and time stamp and until the transmission to the Save back end or the switching device.

The method according to the invention and / or the system according to the invention preferably determine the route traveled by a vehicle between two refuelings and / or charges. Refueling / charging is present, for example, when the tank level or the battery state of charge increases and the speed is zero. If this is the case, the OBD2 adapter records the odometer reading and, if applicable, the GPS position of the vehicle (see below). In addition, the OBD2 adapter detects at which tank level the refueling started and at which tank level it ends. From the two tank levels (battery charge status), the odometer reading and possibly (in bivalent vehicles) the fueled fuel main types as well as the identification numbers of the vehicle and possibly front-end forms the front-end a record and sends it about the standing described optional ways to the back-end. There, the record is saved and processed or first processed and then saved.

At the time of refueling, the tank levels (battery charge states) are clear, because the difference between the unique tank level (battery charge state) at the end of the last refueling and the clear tank level (battery charge state) at the beginning of a refueling can be, for example determine clear fuel consumption (power consumption). From the multiplication of the (unambiguous) subtraction result with the fuel-specific energy content (calorific value) retrievable from the fuel file, it is possible to calculate the (unambiguous) energy input that has accrued on the route between two refueling operations. By multiplying the unique route-specific energy input by the fuel-specific (LCA) GHG emission related to one energy unit (MJ, kWh _H i), the unique route-specific (LCA) GHG emission can be calculated. Other calculation methods that are possible (eg calculation of (LCA) GHG emissions only from fuel consumption levels) produce less clear results.

Preferably, the front-end stores the odometer readings and tank levels (battery charge states) of "his" vehicle at each end of the month, preferably every weekend, more preferably at each end of the day and especially at each end of the hour. consumed fuel to individual months, which can be beneficial if users want to know monthly data.

The sum of the individual data sets with the refueling data listed above forms the fueling history of a vehicle, which is analyzed by the back-end or in the back-end by means of corresponding analysis programs (statistical programs). In particular, the used main fuel type, the fuel consumption which has occurred between two fueling operations and the travel distance of the road vehicle traveled between two fueling operations are determined. The division of fuel consumption by the distance traveled gives the actual average fuel consumption per kilometer. The multiplication by the factor 100 gives the average fuel consumption per 100 km. Multiplying the actual average fuel consumption per km by the fuel-specific calorific value gives the actual energy used per km. Multiplying the actual energy use per km by the fuel unit specific (LCA) GHG emission value gives the actual (LCA) GHG emission of the vehicle per km.

This way of determining the actual (LCA) GHG emission of a vehicle is more accurate than the abbreviated determination of the fuel consumption and the (LCA) GHG emission per fuel quantity (liters, kg), which in principle is also possible - As in the basic variant (see claim 1) is described. Both investigations are more accurate than consumption and emission values, which are determined after certain driving cycles on chassis dynamometers.

More specifically, the consumption and emission data, if not average energy contents and (LCA) GHG emission values of main fuel types, are considered, but fuel grade specific energy content (LCA) GHG emission values. However, the use of these data requires that the fueled and used fuel subtypes are known. Microcontrollers (sensors) and OBD systems have not been able to do this so far. Therefore, according to the invention, a sub-method is used with which the fueled and used fuel subsets are detected. To record fuel subsets, the front end complements the refueling data of the road vehicle with the GPS position of the vehicle it was refueling on. The GPS position is integrated into the refueling record, cached and, in due course, transmitted from the front-end to the back-end as described above. In the back end, in this case, a petrol station file / database is kept next to the vehicle file / database and the fuel file / database. In this the GPS positions of all gas stations and possibly all charging stations are stored, so that the back-end (more precisely, special evaluation software) a comparison between the positions of the vehicles at the time of refueling and the positions of the gas stations (charging points) can make. This can be used to determine when a road vehicle has fueled where. From the petrol station file / database also shows when the gas station was supplied with which fuel subspecies. From the refueling point and refueling time it is possible to determine which fuel subtype the vehicle has fueled. If the refueled fuel subtype is known, the back end of the fuel file / database can read what the calorific value and the (LCA) GHG emission value of the particular fuel subtype is. The further calculation of the fuel consumption or energy input and (LCA) GHG emission values takes place as described above. Since these values are based on the values of fuel subsets, they are relatively accurate (see above).

It may be advantageous to divide the distance traveled between two refueling, e.g. in daily routes or in journeys (see above). It goes without saying that the calculation of fuel consumption, energy inputs and GHG emissions on partial routes can be carried out analogously to the procedure described above for the entire distance traveled between two fueling operations.

The software loaded on the front end may include the function of calculating the distance covered by the motor vehicle by simple subtraction from the detected odometer readings, in particular from the odometer readings resulting from fueling. In this case, the front-end transfers the calculation result either directly to the back-end or via the switching device. However, this calculation of the route can also be performed by the special software loaded on the switching device. In this case, the front-end transmits only the odometer readings to the back-end or to the switch. In a third variant, the calculation of the route can also take place only in the back-end, then transmit the front-end and possibly also the switching device only the odometer readings.

In the event that the front-end does not gain access to the odometer readings of the vehicle, it may determine vehicle traveled distances via vehicle-external sensors or systems, e.g. via GPS modules that are located as stand-alone modules in the vehicle or as components of independent devices. These standalone devices may e.g. a front end, a switch, a navigation system, a smartphone, another user communication terminal or the like. The corresponding GPS module can then transmit the GPS position to the front-end or switch via appropriate interfaces or cables. The front-end or the switch may e.g. capture the GPS positions, if necessary, buffer them and how the other data is transferred to the back-end or determine the driving distance of a vehicle, which is usually measured in km, from currently recorded GPS positions and transmit the result of the determination to the front-end , For further details, reference is made to the state of the art.

However, the distance traveled by the vehicle, usually measured in km, can also be determined via a gyroscope, which, like a GPS module, functions as an independent module in the vehicle or as part of a vehicle system or as a component of a stand-alone vehicle-external device. These standalone devices may be, for example, a front end, a switching device, a navigation system, a smartphone, another user communication terminal or the like. The corresponding gyroscope module or gyroscope device may then transmit the global position to the front-end or switch via suitable interfaces or cables. The front-end or the switching device can, for example, capture the global positions, if necessary, buffer them and transfer them to the back-end like the other data (see independent claims) or determine the route of a vehicle from continuously recorded global positions or changes in location Transfer the result of the investigation to the front-end. For further details, reference is made to the state of the art.

A prerequisite for determining the fuel-specific (LCA) GHG emission quantity, which is usually measured in gC0 ₂ -eq / MJ or in gC0 ₂ -eq / kWh _H i, is the knowledge of the type of fuel. In fact, fuels have very different densities, energy contents (calorific values), GHG emission values and in particular LCA-GHG emission values. Typically, propulsion technologies are defined by the fuel they use.

In the case of monovalent vehicles, the drive technology is deposited according to the invention in the vehicle file / database of the backend. Namely, the main fuel used is clear: gasoline vehicles consume gasoline, diesel vehicles consume diesel fuel, CNG vehicles use CNG, LNG vehicles use LNG, LPG vehicles use LPG, fuel cell vehicles only fill up with hydrogen and electric vehicles use electric power.

For bivalent vehicles, e.g. CNG vehicles whose engines can run on both petrol and natural gas (CNG) must be tracked to determine which fuel is currently being used in the vehicle. Typically, the engine control system provides this data to the on-board diagnostic (OBD) system, from where the front-end can pick it up and store it for later forwarding. If the OBD system does not supply this operating data, the method according to the invention can also determine the fuel types consumed, as described below, fuel-specifically via the tank levels. This applies accordingly to battery-operated electric vehicles.

For full hybrid vehicles with external battery charging (plug-in hybrids), which have two energy sources, namely a conventional combustion engine and a rechargeable battery (battery), track-specific needs to be determined in the vehicle, which energy source used to what extent becomes. Typically, the engine control system supplies this data to the on-board diagnostic (OBD) system, from where the front-end can pick it up and store it for later forwarding. If the OBD system does not provide this operating data, the method according to the invention can also determine the fuel and electricity consumed, as described below, in a fuel-specific manner via the tank fill levels (battery charge states).

In so-called dual-fuel vehicles whose engines can be operated both with one fuel and with the other fuel as well as with almost any mixtures of the two fuels, track-specific in the vehicle must be determined which fuels are currently being used and which relationship. Typically, the engine control system provides this data to the on-board diagnostic (OBD) system from where the front-end can retrieve it and cache it (if the OBD system does not provide this operating data), the method of the present invention can also use the amount of fuel consumed Determine fuel-specific fuel levels as described below. Since each major fuel type can have its own fuel sub-types, each with different energy contents (calorific values) and different (LCA) GHG emissions, the right allocation of fuel consumption to individual vehicles and to individual routes becomes highly complex. For example, a fuel cell vehicle may have even the best sensors; it will not be able to distinguish hydrogen generated from wind power by electrolysis from hydrogen produced from the German electricity mix by electrolysis, or from hydrogen produced by steam reforming from natural gas Chemically all hydrogen subsets are identical, but they have completely different (LCA) GHG emissions.

Thus, the best sensor technology of a conventional petrol (gasoline) powered gasoline vehicle, e.g. whether the crude oil used in the refinery for gasoline distillation originates from Canadian tar sand or from the Brent field of the North Sea or from natural bitumen from Venezuela. Even in this case, all gasoline subspecies are chemically more or less identical, but they also have completely different (LCA) GHG emission values due to the different raw material origin. The same applies to electricity from different sources and biofuels, which also have different production routes, which again lead to different (LCA) GHG emission values.

As long as the refueled fuel sub-types are not detected via the above-described geographical alignment of refueling station and refueling station / refueling station according to the invention and the time alignment between refueling time and refueling station-specific supply of fuel subtypes, the invention permits Nevertheless, the method and the system according to the invention provide a relatively accurate determination of the route-specific energy input and an approximate determination of the route-specific LCA-THG emission. The (lower) calorific values Hi of the individual fuel sub-types deposited in the fuel file / database usually differ relatively little from the (average) calorific value Hi of the main fuel type. If in the back-end the determined route-specific energy input is multiplied by the energy-specific (LCA) emission standard of the main fuel type stored in the fuel file / database, which usually has a (weighted) average value of the (LCA) ) Is still more accurate and realistic than any GHG C0 ₂ emission value.

The front-end detects and stores the tank levels (battery charge states) as well as the odometer readings, preferably at the beginning of a refueling (battery charging) and at the end of a refueling (battery charging). The loaded on the front-end software may include the function to determine the amount of fuel (charged amounts of electricity) fueled by the vehicle by simply subtracting the tank level (battery state of charge) at the beginning of refueling (charging) of the tank level (battery state of charge ) at the end of refueling (charging). In this case, the front end transmits the calculation result directly via communication network or via switching equipment and communication network. The calculation of the fuel quantities (charged amounts of electricity), however, can also be performed by the special software loaded on the switching device. In this case, the front end transmits only the tank levels (battery charge states) to the switching device. In a third variant, the calculation of the fuel quantities fueled (charged amounts of electricity) can also be done only in the back-end, then transmit the front-end and possibly the switching device only the tank levels. In an advantageous development, the front end on the tank levels (battery charge states) can also determine the actual fuel consumption (power consumption) by simply subtracting the tank level (battery state of charge) at the beginning of refueling (charging) of the tank level (battery level). State of charge) at the end of the last refueling (charging). In this case, the front-end transfers the calculation result either directly to the back-end or via the switching device. However, the calculation of the fuel consumption quantities (power consumption quantities) can also be performed by the special software loaded on the switching device. In this case, the front end transmits only the tank levels (battery charge states) to the switching device. In a third variant, the calculation of the consumed fuel quantities (consumed amounts of electricity) can also be done only in the back-end, then transmit both the front-end and the switching device only the tank levels.

The determination of the fuel consumption quantities (power consumption quantities) can also be done by adding incremental fuel flow rates (flow rates), which are detected by the engine control, a flow meter or functionally identical components or systems. It can also be done by recalculating the fuel consumption quantities from (stoichiometric) exhaust gas quantities (masses, volumes). With regard to further details, reference is made in both cases to the corresponding state of the art.

The transmission of the data (values) acquired by the front-end and / or calculated by himself directly via communication network to the back-end or indirectly via switching equipment and communication network to the back-end preferably takes place via an air interface, which particularly preferably has a Bluetooth or WiFi / WLAN interface is. This makes it possible to use almost any type of smartphone, which are mostly Bluetooth or WiFi / WLAN-enabled, as a switching device. However, it is also possible to connect the front-end (the OBD2 adapter) by cable to the switch and to transmit the data from the front-end via this cable to the switch. However, data transmission in 802.11b format is also possible. The switch may also be a transceiver subsystem of the vehicle that can dispatch data over an existing communication network, e.g. a navigation system.

The front-end and / or the switching device give the detected or calculated operating data of the road vehicle, which are relevant, preferably odometer readings, in particular odometer readings during refueling, distances traveled between two refuelings, information on the types of fuel refueled, tank levels and / or fuel quantities refueled, GPS position of the refueling location, vehicle ID, front-end ID, etc., preferably on an on-event basis, particularly preferably immediately or as soon as possible after refueling and / or recharging.

The transmission of data from the switch to the back-end is via an existing communication network as described above, that is, the method and system of the invention utilize the communication technology in the switch (in the smartphone). As communication networks are in particular those in question, which work on Wi-Fi, Bluetooth, LAN or WLAN basis.

The inventive method also includes the possibility that the front-end transmits its data, bypassing the switching device directly via a communication network to the backend, preferably via mobile - which requires that the front-end has a SIM card, the first access to a mobile network allows. Particularly preferably transmits the front-end transmits the data to the back-end via the Internet - which requires the presence of a corresponding interface in the front-end. However, it is also possible that the switching device transmits the data over a telephone network, via a cable network, via a proprietary network or the like.

The data delivered directly from the front-end to the back-end via the communications network need not exactly match the data that the front-end has obtained from the OBD2 system of a road vehicle. This is what is meant in this specification and in the claims when the term "or a version of this data" is used, especially the communication between the front-end and the switch and between the switch and the back-end, also here In general, the data records on the way from the OBD2 system via the front-end and possibly the switching device via the communication network to the back-end are usually slightly changed and the data records read from the OBD2 system of the road vehicle Of course, the back-end is able to extract the relevant data from the transmitted data sets.

The transmitted to the back-end motor vehicle operating data so u.a. a selection from the data vehicle ID, front-end ID, ID of the switching device, odometer reading, distance covered and possibly sub-sections, refueled fuel types (types of electricity), used fuel types (types of electricity), tank levels (battery charge status), fueled Fuel quantities (quantities of electricity), consumed fuel quantities (quantities of electricity) and possibly further vehicle-specific information, characteristics and criteria (eg date, time, GPS coordinates, oil level, seat occupancy, payload, freight / work etc.). All data, their transmission to a central office for (later) evaluation for experts of the affected branches (automobile, transport, traffic, fuels incl. Biofuels and synthetic fuels, environment, climate, health, taxes, finances) as well as for private owners and Drivers can make sense.

Either the vehicle-specific data required for calculating fuel consumption, energy inputs and / or GHG emissions are delivered to the back-end or the back-end calculates them from other delivered operating data. This data is stored or stored in the back-end with and without previous calculation in the vehicle file or vehicle database, ie in the raw state or as already processed operating data. The vehicle database is adapted to receive the data of a plurality of vehicles, but at least the data of a motor vehicle. Ideally, the total Kraftstoffverbrauchsbzw. Energy usage history of a motor vehicle stored in this vehicle file / database, possibly supplemented by the (LCA) GHG emission history.

The procedure is the same when determining the type of fuel consumed. Either the information on the fuel types consumed by the back end for the calculation of the vehicle and route-specific energy use and the (LCA) GHG emissions is either delivered to the back end or the backend determines this data the vehicle data supplied on the occasion of vehicle registration. Like the route data, these data are stored or stored in the back-end with and without previous calculation in the vehicle file or vehicle database, ie in the raw state or as an already processed master data record. For example, these data may indicate that a motor vehicle is a monovalent diesel vehicle. It follows logically that this motor vehicle can only use the main fuel type "diesel fuel." The same applies to all monovalent motor vehicles and largely also for hybrid vehicles as (liquid) fuel only gasoline fuel and use. As soon as electricity comes into play, its electric drive is affected (see above).

Either the vehicle and distance-specific fuel consumption quantities required by the back-end for the calculation of the (LCA) GHG emissions are delivered ready-calculated or the back-end calculates them from the delivered operating data such as, for example. from the tank levels. Like the route data, these data are stored and stored retrievably in the back-end with and without previous calculation in the vehicle file or vehicle database, ie in the raw state or as already processed operating data.

Although they can be very large, these mileage and fuel consumption data are not sufficient to calculate vehicle-specific energy use for different vehicles and to compare the results. Only the unification of the various fuels on a universal energetic unit makes this possible. It is therefore necessary to know the fuel-specific energy contents (calorific values). While, for example, diesel fuel has an energy content or calorific value of approximately 9.9 kWh _H i / liter and gasoline has a value of approximately 8.7 kWh _H i / liter, the energy content of CNG is 10.5-13.6 kWh _H i / kg and that of hydrogen rd. 32.2 kWh _H i / kg. A direct comparison of the differently measured fuel consumption levels would be misleading.

According to the invention, the fuel-specific energy contents (calorific values) are stored in the fuel file (fuel database) of the back-end. Since they can change, it makes sense to store them centrally, where they could easily be changed. With a filing of this fuel-specific data in the software of the front-end or in the software of the switching device, which is also possible with each data change would require a variety of software update, namely the update of each switch and / or each front-end , Future users of the method according to the invention or future operators of the system according to the invention must, depending on the individual design of their business model, determine which variant they want to realize, each has its advantages.

If they are not delivered by the front-end or the switching equipment via the communication network, the amounts of energy used in the back-end are calculated by multiplying the fuel consumption quantities by the respective energy contents (calorific values) of the various fuels and - if they are at Need not always be recalculated - stored in the vehicle file / database retrievable.

By reference to the distances covered, or more precisely by the division of the absolute amounts of energy consumed by the corresponding route, common quota values such as e.g. Energy input (quantities) / 100 km and / or energy input (quantities) / km calculated. By multiplying these results by the respective energy contents of the respective fuels, the back end can also calculate and display the fuel consumption (s) / 100 km or per 1 km. It goes without saying that these data can also be stored in the vehicle database and that these data can be converted into ranges, e.g. in miles / gallon.

The results, which are raised to a uniform standard, make the energy inputs of the various drive technologies comparable. Interested parties can directly compare the efficiency of individual and all drive technologies achieved in everyday operation.

By dividing tank levels (or tank capacities) by fuel-related quotas (eg those that refer to one or 100 km, such as 8.5 1/100 km), the back- End also calculate usual ranges, eg the range in km / tank filling. Also possible is the return transmission of the vehicle-specific energy or fuel consumption (and possibly other data) from the back-end via communication network and switching equipment to the front-end and from there to the vehicle diagnosis system or directly to the appropriate vehicle system (eg engine control) to calculate the remaining range from these data and the tank levels. The calculation results can then be displayed to the driver inside the vehicle via a driver information system.

The sole knowledge of the energy input is not sufficient to calculate the (LCA) GHG emission. This requires the fuel-specific (LCA) GHG emission values (emission factors). Usually, these relate to the energy content of the respective fuel. When determining the LCA emission values, not only the exhaust gases or emissions resulting from the stoichiometric combustion occurring in the engine are taken into account, but, according to the LCA approach, also evaporative emissions and emissions arising in the process chain upstream of the energy input (cf. ). When used in the specification and claims of this disclosure, the term "(LCA) GHG emission" is meant to be both (stoichiometric) GHG emissions and LCA-GHG emissions.

According to the invention, the fuel-specific (LCA) GHG emission values are stored in the fuel file (fuel database) of the back-end. Since they can change, it makes sense to store them centrally, where they could easily be changed. With a filing of this fuel-specific data in the software of the front-end or switching device, which is also possible with each change in data would require a variety of software update, namely the update of each switch and / or each front-end. Future users of the method according to the invention or future operators of the system according to the invention must, depending on the individual design of their business model, determine which variant they want to realize, each has its advantages.

If they are not delivered from the front-end or the switching center via the communication network, the vehicle and route-specific emitted (LCA) GHG emission levels in the back-end are multiplied by the route-specific energy input quantities with the respective energy-specific (LCA) ) GHG emission values of the various fuels are calculated, ie by multiplying the absolute route energy input quantities measured in MJ or kWh _H i by the fuel-specific energy unit and in gC0 ₂ -equivalent / MJ or in gC0 ₂ -equivalent / kWh _H i measured (LCA) GHG emission values, also referred to as "life cycle greenhouse gas intensity" (see EU Directive 2015/652 / EC) .The result is the absolute (LCA) GHG measured in gC0 ₂ -eq per line. Emission The calculation result - if it should not be recalculated again and again if necessary - stored in the vehicle file / database retrievable rt.

By referring to the distance covered, or more precisely by dividing the absolute emission quantities measured in gC0 ₂ -eq per route by the corresponding distance measured in km of the road vehicle, common quota values, such as the (LCA) GHG emission quantity / 100 km, are calculated and / or calculates the (LCA) GHG emission amount / km. It goes without saying that this data can also be stored in the vehicle database and that this data can be converted into (LCA) GHG emission amount / 100 miles and / or the (LCA) GHG emission quantity /Mile.

The results make the (LCA) GHG emissions of the various drive technologies that are actually produced in everyday operation comparable. Anyone interested can use the The achieved environmental impact of individual and all drive technologies can be directly compared.

In a development of the method according to the invention, the determined data can also be stored in the software application of the front-end or in the software application of the switching device, which would make this at least with regard to this function the back-end.

It is possible that the vehicle file / database is not run and operated in the backend, but on a foreign server. The same applies to the fuel file / database and the gas station file / database, they can also be operated outside the actual back-end. If these files / databases are not operated in the back-end, but outside, this means in the context of the invention, a partial outsourcing of the back-end function. That is, the potentially physically outsourced components of the back-end still constitute a functional part of the back-end, despite the outsourcing of functional components. Thus, the back end, as understood in this disclosure, would also extend to the paged files / databases. M.a.W., an outsourcing of the files / databases so in the sense of this publication be understood that it moves the system boundaries of the system "back-end" to the outside of the systems that host the outsourced back-end components or include.

Back-end fuel and energy use values and (LCA) GHG emissions are of great interest to a variety of users. First of all, they are of interest to the drivers and owners of motor vehicles who are connected to the inventive system and / or use the inventive method. They can now easily determine route-specific, with which fuel consumption they burden the natural energy reserves and what contribution they make with their driving behavior to the local, regional, national, national and international GHG emissions and thus to global warming. In other words, they get to know the part of their C0 ₂ footprint that they create through their mobility behavior, regardless of more or less artificial consumption and emission levels published by vehicle manufacturers, environmental institutes, government agencies, NGOs, and governments ,

The individual user can view "his" data or the data of his road vehicle via Internet, preferably after entering his PIN and / or his password.To enable this, the back-end has a web server Users can also view aggregated data, such as the average route specific fuel consumption of all cars, all cars, all models of an automaker, all cars in one country, all vehicles of "his" model, etc. Consumption and emission levels can be the basis for sharpening environmental awareness and behavioral change. The user may e.g. be motivated to switch to more environmentally friendly propulsion technology or even change their mobility behavior.

For example, if based on actual real-world data, the invention helps to demonstrate that CNG-fueled VW CNG gulfs emit on average 25% less (LCA) GHG CO ₂ into the Earth's atmosphere than gasoline gulfs on a daily basis, CNG gulfs fueled with BioMethane 70% less, CNG gulfs fueled with straw ^methane even 90% less, and CNG ^gulfs fueled with straw ^methane zero- ^emission even 100% less, then a much faster transition from conventional propulsion technology to advanced propulsion technology, because the data are based on everyday experiences. This process of transition can still be accelerated by drivers, owners and managers of vehicles (eg fleet managers) with monthly notification It is made clear how great the C0 ₂ footprint of their vehicles actually is as a result of their driving objectives and driving style.

With the data collected in day-to-day traffic, the European Research Group on Mobile Emission Sources (ERMES), which is an association of independent European institutes and responsible for the "development" of so-called road traffic emission factors, could identify these emission factors, which have so far been based on theoretical models ( Driving cycles), significantly improve (see above).

With improved ERMES values, the information provided in the Emissions Factor Handbook (HBEFA) would also be more accurate as ERMES identifies the emission factors found in HBEFA. First, only the carbon dioxide emission levels would be improved, in advantageous developments of the invention, other emissions such as nitrogen oxide, methane, non-methane hydrocarbon, benzene, carbon monoxide, particulate (particulate matter), ammonia, di-nitrogen oxide - (nitrous oxide) and sulfur dioxide emission.

With improved HBEFA values, the statements based on the TREMOD expert simulation model were also developed by the Federal Environmental Agency (see above). It is also possible for third software applications to access the data generated by the system according to the invention or by the method according to the invention and to evaluate it in turn.

It is also possible to give each road vehicle an OBD2 adapter and measure the amount of the vehicle tax or other tax from the level of e.g. LCA GHG emissions emitted in one year. It is conceivable, e.g. the determination of a specific tax-free LCA-THG emission quantity. As soon as this quantity is exceeded, a certain tax rate applies, which increases more and more if other (higher) limits are exceeded. The individual gases could be assigned specific tax rates.

The basic method described in claim 1 does not yet have any details for connecting the front end to the vehicle diagnosis system. It merely describes that the front end is connected to one or more electronic components of the vehicle and that it is suitable to obtain operating data of the vehicle from these components and to read them. However, it is advantageous if the front-end gets access to the OBD system of the motor vehicle, which usually has an OBD socket or an SAE plug contact. The communication is then more or less standardized, which significantly reduces the technical effort on the part of the process. It is advantageous if the front end has such a plug contact, since it can then be used in any motor vehicle having such a plug contact. This is the case with almost all motor vehicles produced in the USA from 1996 and in Europe from 2001 onwards. Since the road vehicles are on average 9.5 years old, almost all road vehicles that are on the road today can be equipped with OBD adapters if these OBD adapters have an OBD connector. It's even more of an advantage if the front-end plug is compatible with the latest version of the OBD jacks. The current version is the OBD2 plug-in contact, with the OBD2 mother socket installed in the vehicle and the OBD2 father plug in the diagnostic tools or in the OBD2 adapters. With such a connector, the front-end (the OBD2 adapter) can be used without further adaptation measures or special versions of all modern road vehicles. It goes without saying that the OBD connector on the front-end not only physically fits the OBD socket of the vehicle in question, but also with regard to the pin assignment and the transmission protocol, even if it varies from vehicle manufacturer to vehicle manufacturer. Manufacturers should differ. For example, while Ford uses the SAE-J1850-VPW communications protocol, GM uses the SAE-J 1850-VPWM protocol, Toyota & most European manufacturers the ISO protocol, more specifically the ISO 9141-2 protocol, some of the Hyundai & Mercedes models the KWP protocol, more specifically the KWP 2000 protocol and the so-called "Next-Generation Vehicles" the newer CAN protocol ( Vehicles from model year 2004).

The front-end (hereafter synonymously referred to as OBD2 adapter, without this designation being intended to limit the above-mentioned front-end options to an OBD2 adapter) may, in addition to the basic components required for its operation, A selection of the following components includes: OBD2 connector, microcontroller or microprocessor, program memory, data memory, Bluetooth chip, cellular transceiver module (modem), cellular antenna (external or embedded in the circuit board / circuit board or integrated into a housing of the mobile modem), SIM card or slot for at least one SIM card, slot for a memory extension, memory expansion, WiFi / WLAN interface, interface for memory expansion, receiver and / or evaluation unit for global positioning data (eg NAVSTA GPS, GLONASS GPS, GALILEO GPS, BEIDOU GPS), battery or battery, current regulation or management. For further details, reference is made to the state of the art (in US 6636790 (Lightner et al.), US6832141 (Skeen et al.), US2008 / 0015748 (Nagy) and US9224249 (Lowrey et al.) Are, for example Embodiments of OBD2 adapters are described).

The OBD2 connector is advantageous because the OBD2 adapter can be used in almost all road vehicles without any modifications or conversions (see above). A microprocessor and a program memory are advantageous because the OBD2 adapter can execute with these work instructions (software programs). A data memory is advantageous because the OBD2 adapter can store with this operating data of the motor vehicle. This is required if the OBD2 adapter is not connected to the switch while the vehicle is producing relevant operating data. For example, A smartphone may be broken or missing during a ride. An internal power supply (battery / rechargeable battery) is advantageous because it does not lose any data when the OBD2 adapter is removed from the OBD2 socket of the vehicle. A Bluetooth chip is useful because the OBD2 adapter with this Bluetooth-enabled switch can be loaded with software or because it can send data to that switch. The same applies to a WiFi / WLAN module. The cellular transceiver module, the SIM card, and the cellular antenna are useful because the OBD2 adapter can use this via cellular network to directly send vehicle operational data to the back end. A WiFi / WLAN interface is advantageous because the OBD2 adapter can directly send vehicle operating data to the backend via the Internet. An interface for memory extensions is advantageous because the OBD2 adapter can run with these more complex work instructions (software programs) and / or store a larger amount of data (between). A GPS module is advantageous because, in the event that a vehicle diagnostic system can not provide GPS coordinates, the OBD2 adapter will detect the GPS position itself and this information along with the vehicle's operating data to the back -End can transfer. Typically, the OBD2 adapter is powered by the vehicle via the OBD2 socket (PIN 16) of the vehicle with the power required for its operation. However, it may happen that the OBD2 adapter is disconnected from the OBD2 jack of the vehicle (e.g., during vehicle service stops) or drops off. Without electricity, he would lose the cached data and possibly even the software programs. The battery makes it possible that this does not happen.

Many vehicles do not have a GPS module. Their OBD system is therefore unable to provide GPS coordinates. However, the provision of geographical coordinates may be required, in particular if an adjustment of the refueling or charging places with filling station locations for the purpose of filling station identification is to take place (see above). A procedure that uses operating data of a vehicle tool is supplemented with GPS data, even if the vehicle systems can not provide this information or not, is therefore advantageous, especially when the position of the localities to be transmitted to the back-end, where the vehicle fueled or his Has charged batteries. In the method according to the invention, provided the appropriate software and hardware, both the front end and the switching device can supply this position data.

With regard to the charging of vehicle batteries with electricity, the charging location may be relevant, namely, when a charging station explicitly an eco-power source has been developed. This may be the case in the construction of wind, photovoltaic, hydropower and other green electricity power plants. In this case, the charge current can be assigned a different (LCA) THG value than the average (LCA) THG value of a current mix.

The basic method described in claim 1 does not yet have a WiFi / WLAN interface. However, a WiFi / WLAN interface is advantageous because it allows either the switch or the front-end to send vehicle operational and possibly additional data to the back-end via the Internet. A data transmission via the Internet can be more cost-effective than a transmission via mobile radio network or another communication network, in particular if the transmission frequency and / or the data volume transmitted are large.

Furthermore, it is advantageous if the inventive method, which largely involves the transmission of data, comprises the use of a Bluetooth, a WiFi / WLAN protocol and / or a USB protocol. With these protocols, it is easier and less expensive to implement the method. In particular, the initialization of the front-end and the communication between front-end and switching device are simple and less expensive if they can be made wirelessly with Bluetooth or wired according to the USB standard.

The range of fuel types is large and they are also available in many different mixtures and subspecies. It is therefore of advantage if the fuel file / database, which is preferably carried out in the backend, is suitable for the technical properties and characteristics, preferably (LCA) GHG emission values, of a multiplicity of fuels, preferably of main fuel types and, more preferably, fuel subsets, via at least one suitable interface to receive, store and retrieve. The fuels listed in the fuel file / database may include a selection of the following major fuel types: petrol, diesel, kerosene, CNG, LNG, LPG, methanol, electricity, hydrogen, nitrous oxide, and possibly other fuels. main types. They may also include a selection of the following fuel subsets: diesel of different origin, biodiesel of different origin, various mixtures of diesel and biodiesel, gasoline of different origin, bioethanol of different origin, various mixtures of gasoline and bioethanol, kerosene of different origin, organic kerosene different Origin, diverse mixtures of kerosene and BioKerosin, CNG of different origin, BioMethan of different origin, various mixtures of CNG and BioMethan, LNG of different origin, LBM (Liquefied BioMethane) of different origin, various mixtures of LNG and LBM, LPG of different origin, nitrous oxide of different origin , Synthetic methane (SynMethane) of different origin, various mixtures of SynMethane of different origin, hydrogen of different origin, various mixtures of hydrogen of different origin, electricity difference Licher origin, various mixtures of electricity from different sources, other fuels from different sources and possibly other fuel subspecies. In the basic version of the method according to the invention described in claim 1, the applicant claims protection that the back-end of the traveled distance of the motor vehicle, the fuel or power used on this route, the consumed route-specific fuel quantities and the fuel / Current type-specific (LCA) GHG emissions determines or calculates which (LCA) GHG emission quantities (masses, volumes) the motor vehicle emitted on the traveled route into the earth's atmosphere. This can be further specified in an advantageous manner. This task can namely take over a computer with a special computer program (emission computer with suitable software), which can be part of a server. Furthermore, the determined values can be further specified. The method is easier and less expensive to perform, if they are known. The Applicant therefore claims protection for a method in which the back-end of the transmitted vehicle-specific data vehicle-specific calculates, stores and / or exports via a suitable data interface at least one of the following technical values: the emission of (LCA-) C0 ₂ - equivalents in absolute terms, the (LCA-) C0 ₂ emissions per trip, the (LCA-) C0 ₂ - emissions per period (day, week, month, year, vehicle lifetime, etc.), the (LCA-) C0 ₂ emission amount between two refuelings, the emission of (LCA-) C0 ₂ equivalents in a relative quota, the (LCA-) C0 ₂ emission amount per km of travel, the (LCA-) C0 ₂ emission amount per 100 km of travel , the (LCA) C0 ₂ emission amount per fuel quantity (kilogram, ton, liter, gallon), the (LCA-) C0 ₂ emission amount per unit of energy (MJ, kWh) as well as the emission of (LCA-) C0 ₂ -equivalent in other technical representations or values.

In the event that the OBD2 standard is replaced by a successor standard, it is advantageous if the inventive method can use this successor standard. It is particularly advantageous if the vehicle-specific data can be transmitted wirelessly via a suitable air interface, preferably via Bluetooth to the switching device or via another air interface such as, for example, WiFi / WLAN to a communication network.

The implementation of the method according to the invention is simpler, faster and less complicated if the switching device is a device with access to a communication network, preferably a smartphone. Namely, since such user communication terminals usually have access to a communication network, both the specific software controlling the exchange and the software controlling the front end can be easily downloaded to this exchange. In addition, the software that controls the front-end can be easily loaded from these user communications terminals to the front-end.

An advantageous development of the invention is the merging of located in the front-end (partial) processes and the (sub-) processes that are located in the switching device, this is particularly advantageous because less expensive if the merged (part -) Processes only in one device (component, device) run. This only one component (device) may be an adapter, interface module, motor vehicle component or system, user terminal, navigation device, smartphone, tablet, laptop, PC or the like.

It is even more advantageous when large parts of the method according to the invention run in only a single device, that is to say when some of the functions of the back-end are also integrated in this single device. This eliminates e.g. Much of the communication between the vehicle and the central location, the vehicle does not have to dial into the back-end as often.

According to the basic version of the method according to the invention described in claim 1, it is not specified in detail which data the method accurately detects. It is essential for the implementation of the procedure It is advantageous to know which vehicle-specific data is to be recorded and transmitted directly or via the switching device to the back-end, preferably as additional data. These data may consist of a selection of the following values: distance traveled since commissioning, distance traveled since last or any previous refueling, refueled fuel types or charged types of current, route-specific fuel / electricity types, fueled energy or fuel consumption. Fuel quantities, route-specific spent Energiebzw. Fuel quantities, seat occupancy specific occupancy, number of persons carried on a specific route, specific weight transported (gross, tare, net), absolute stoichiometric exhaust gas mass (mass, volume), total stoichiometric exhaust gas volumetric flow, total stoichiometric mass flow of exhaust gas, absolute nitrogen oxide emission quantities (volume, mass), nitrogen oxide emissions in a relative quota value, proportion of nitrogen oxide emission amount in total exhaust gas quantity, proportion of nitrogen oxide emission in total exhaust gas volume flow, proportion of nitrogen oxide emission in total exhaust gas mass flow, absolute particulate matter emission quantity (volume, mass), Particulate matter emission in a relative quota value, fraction of particulate matter emission amount in total exhaust gas quantity, proportion of particulate matter emission in total exhaust gas volumetric flow, proportion of particulate matter emission in total exhaust gas mass flow, global geographical vehicle position, global geographical vehicle Position at refueling, St nitrous oxide emission, nitrous oxide emission, sulfur dioxide emission, carbon monoxide emission, particulate matter emission, noise emission, oil level, oil consumption, tire wear, tire pressure, tank level, tank reach, battery state of charge, battery range, vehicle angle to longitudinal axis, vehicle angle to lateral axis, airbag Tripping, cooling water temperature, starting behavior, emergency call signal and other relevant values or data for experts.

As described above, although energy and emissions values relating only to major fuel types may be used to approximate a correct image of vehicle-specific fuel consumption, energy inputs, and emissions, this will not be accurate until the energy and gas emissions Refer emission values to the fuel subspecies. It is therefore advantageous if the sub-process described below is fully or partially integrated into the process according to the invention:

The global geographical position of the motor vehicle, preferably the global geographical position (GPS position) of the motor vehicle during its refueling or charging, is determined by a suitable vehicle-internal component (position sensor, NAVSTAR GPS / GLONASS / GALILEO). / BEIDOU receiving and evaluation device or the like), from a suitable vehicle-external device (position sensor, navigation device, NAVSTAR GPS / GLONASS / GALILEO / BEIDOU receiving and evaluation device, smartphone, other user terminal or the like) or from the front end itself, and the front end forwards the position data to the switch;

The vehicle-specific data transmitted to the back-end includes the global geographical position (GPS position) of the motor vehicle during its refueling or charging;

• in the back-end, at least one file (petrol station file) with petrol station or loading point-specific data is operated or maintained and the petrol station and vat-specific data of the petrol station file contain information on the global geographical position of the individual petrol stations;

• the petrol station file contains petrol station-specific information on the fuel sub-types dispensed at the individual petrol station, eg origin / type of diesel fuel dispensed, origin / type of biodiesel fuel dispensed, actual mixture ratio in the case of diesel / biodiesel mixtures (B7), origin / type of petrol dispensed, origin / type of bioethanol dispensed, actual mixing ratio for mixtures of petrol and bioethanol, origin / type of CNG, origin / type of bio-methane, actual mixture ratio Mixtures of CNG and bio methane, origin / type of LNG, origin / type of LBM (Liquefied BioMethane), actual mixing ratio for mixtures of LNG and LBM, origin / type of LPG, source / type of synthetic methane (SynMethans), actual mixing ratio Mixtures of SynMethane of different origin or type, origin / type of hydrogen, actual mixing ratio for mixtures of hydrogen of different origin or type, origin / type of stream, actual mixing ratio for mixtures of electricity from different sources, other information these fuel subsets, other fuels;

• the back-end detects or calculates with which amounts of energy (quantities of fuel, amounts of electricity) the motor vehicle has been refueled or charged or with which tank / battery charge conditions the refueling started and with which tank / battery charge conditions the refueling or charging were terminated;

• To identify the gas station where the vehicle was fueled or charged, takes place in the back-end, a comparison between the transmitted from the front-end global geographic position of the vehicle refueling or -aufladung and in the gas station file of Back-ends stored global geographical positions of gas stations or charging points;

• For the identification of the fuel subspecies with which the motor vehicle was refueled or charged, a comparison takes place in the back-end between the refueling data determined by the back end, in particular refueling data relating to the main fuel types, and that in the refueling stations File of back-end stored gas station-specific fuel subspecies;

• the back-end detects or calculates which route the vehicle traveled between the last and the penultimate refueling / recharge or between the last and any refueling / recharge prior to it;

The back-end detects from the transmitted vehicle-specific data, which fuel subsets the vehicle traveled on the route between the last and the penultimate refueling / recharge or between the last and any previous refueling / recharge;

• the back-end calculated from the route-specific fuel sub-types, the route-specific consumed energy and fuel quantities, and the fuel-type specific, energy-related (LCA) GHG emissions, which (LCA) ) GHG emission levels the motor vehicle on the distance covered, per unit time, per period, per km, per 100 km, per trip, since commissioning, based on a passenger kilometer or based on one ton-kilometer has emitted into the earth's atmosphere.

In this sub-method which supplements the method according to the invention, the information about where the vehicle is refueled or charged is of central importance. The GPS position of the vehicle at the time of refueling can be determined, without further intervention by the driver and without the involvement of other systems (such as payment or billing systems), at the filling station where the vehicle was refueled. Position of the refueling location (delivered to the back-end from the front-end or switch) with the GPS position of all filling stations and charging stations - which presupposes the existence of a petrol station database. Finally, if it is still stored in the gas station database, which fuel sub-types currently dispenses the respective gas station (this can change from fuel supply to fuel supply), then the back-end (possibly over a time alignment) more or less effortlessly Determine which fuel subsidence the respective vehicle has fueled. Further reference to the fuel database, in which the energy contents (calorific values) and (LCA) emission values of the individual fuel sub-types are stored, can finally be determined, which amount of energy the respective motor vehicle uses on a given route and which (LCA) ) Has emitted it into the environment.

Since a motor vehicle can basically fill up and use different types of fuel and, in principle, different types of electricity (wind, photovoltaic, water, geothermal, biomass, natural gas, coal, lignite, nuclear Electricity, electricity from bio methane, electricity from biogas, etc.), finds a favorable refinement of the determined and calculated by the departure from fuel main species-specific averages and the turning to fuel-subsistence-specific energy contents and appropriate emission values Data instead. In other words, data collection becomes more accurate.

The basic method and the advantageous developments described above relate to the determination of the actual vehicle-specific fuel consumption in everyday life, the corresponding energy input and the (LCA) GHG emissions resulting from this use of energy. It is advantageous to additionally know other emission values as they result from the everyday use of motor vehicles, e.g. nitrogen oxide emissions, particulate matter emissions, carbon monoxide emissions, nitrous oxide emissions, benzene emissions, sulfur dioxide emissions and ammonia emissions - which is a reason for the existence of E MES (see above). To determine these further emissions, it is i.d.R. required to record the total amount of exhaust gas. This is, as stated above, again dependent on the route, the drive technology, the handling, the fuels used, their energy content, etc., etc.

In order to capture the amount of exhaust gas arising in everyday traffic causally (ie by vehicle), the inventor proposes to integrate the following sub-method in the basic method and / or its advantageous developments:

The vehicle-specific exhaust gas volumetric flow or exhaust gas mass flow is determined by at least one suitable vehicle-internal component (exhaust gas meter or the like) or by a suitable vehicle-external device and transmitted to the front end and the front end is routed the exhaust gas data on to the switching device; for execution, reference is made to the corresponding state of the art.

The vehicle-specific data transmitted from the front-end via the exchange to the back end includes exhaust gas data of the motor vehicle, preferably total exhaust gas quantity data;

The back-end acquires, calculates, stores or exports data indicating which amounts of exhaust gas (volumes, masses) the motor vehicle on a particular route, per unit of time, per period, per km, per 100 km, per trip, since commissioning, as volume fraction of the exhaust gas volume flow, as mass fraction of the exhaust gas mass flow, mass-related to a passenger-kilometer, volume-related to a passenger-kilometer, mass-related to one ton-kilometer or volume-related to one ton-kilometer emitted. Alternatively, the back end can also calculate the vehicle-specific exhaust gas volume flow and / or the exhaust gas mass flow stoichiometrically from the known fuel consumption or the known energy input. For execution, reference is made to the corresponding state of the art.

For advantageous determination of the previously not exactly known nitrogen oxide emissions, the inventor proposes to use a device (NO _x sensor, N0 ₂ sensor, according to the principle of conductivity change of easily oxidizable and reducible gases working sensor or the like) suitable is to determine and communicate via a suitable data interface with which nitrogen oxide emissions of the exhaust gas flow rate of a motor vehicle is effectively loaded (taking into account the dry / wet correction factor). The determined nitrogen oxide volume flows are converted into nitrogen oxide emission mass flows. Subsequently, both nitrogen oxide streams or either of them in absolute quantities or as quota values per time unit, per period, per km, per 100 km, per commissioning, as volume fraction of the exhaust gas volumetric flow, as mass fraction of the exhaust gas mass flow, are mass-referenced to a passenger. Kilometers, volume-related to one passenger-kilometer, mass-based to one ton-kilometer, volume-related to one ton-kilometer or in relation to the traveled distance.

In order to detect vehicle-specific and route-specific nitrogen oxide quantities arising in everyday traffic causally (ie advantageously), the inventor proposes, in particular, to integrate the following sub-method into the basic method and / or its above-mentioned advantageous developments:

• The vehicle-specific proportion of at least one nitrogen oxide in the exhaust gas flow rate or the proportion of at least one nitrogen oxide in the exhaust gas mass flow of a motor vehicle is at least one suitable vehicle-internal component (NO _x sensor, N0 ₂ sensor, according to the principle of conductivity change of easily oxidizable and reducible gases operating sensor or the like) or by a suitable vehicle-external device and transmitted to the front-end or the switching device; for execution, reference is made to the corresponding state of the art.

The vehicle-specific data transmitted to the back end includes nitrogen oxide data of the motor vehicle;

The back-end acquires, calculates, stores or exports data indicating which amounts of nitrogen oxide (volume, mass) and / or nitrogen oxide content (proportions of exhaust gas) the motor vehicle on a particular route, per unit time, per period, per km, per 100 km, per trip, since commissioning, as a volume fraction of the exhaust gas flow, as mass fraction of the exhaust gas mass flow, mass-related to a passenger-kilometer, volume-related to a passenger-kilometer, mass-related to one ton-kilometer or volume-related to one ton-kilometer emitted.

Alternatively, the back-end may also stoichiometrically calculate the vehicle-specific nitrogen oxide volumetric flow and / or the nitrogen oxide mass flow from the known fuel consumption or the known energy input, taking into account the excess air factor and the effects of nitrogen oxides reduction systems. For further implementation, reference is made to the corresponding state of the art.

For the advantageous determination of the so far not exactly known particulate matter emissions, the inventor has developed a further development of his method, namely the use of a device (particulate matter sensor, particle sensor, soot particle sensor, working with special differential signal processing sensors or the like), which is suitable , determine and provide a suitable data cut parts with which particulate matter emissions of the exhaust gas mass flow and / or the exhaust gas flow rate of a motor vehicle are loaded. Then, in the following, vehicle-specific analog determination of the (LCA) C0 ₂ emission determines how high the particulate matter emission mass flow and / or the particulate matter emission flow of a motor vehicle absolute, per unit time, per period, per km, per 100 km, per trip, since start-up, as a volume fraction of the exhaust gas volume flow, as mass fraction of the exhaust gas mass flow, mass related to a passenger kilometer, volume related to a passenger kilometer, based on one tonne-kilometers, volume related to one tonne-kilometers or in relation to the traveled distance.

In order to detect vehicle-specific and route-specific the amount of fine dust arising in everyday traffic causally (ie in an advantageous manner), the inventor proposes in particular to integrate the following sub-method in the basic method and / or its above-mentioned advantageous developments:

• The vehicle-specific proportion of particulate matter in the exhaust gas flow rate or the proportion of particulate matter in the exhaust gas mass flow of at least one suitable in-vehicle component (particulate matter sensor, particulate sensor, particulate matter sensor, sensors working with special differential signal method or the like) or determined by an appropriate vehicle-external device and transmitted to the front-end or transmit the switching device to the back-end for forwarding;

The vehicle-specific data transmitted to the backend includes fine dust data of the motor vehicle;

• the back-end acquires, calculates, stores or exports data that indicates which particulate matter (volume, mass) and / or particulate matter (proportions of exhaust gas) the vehicle has emitted on a specific route.

The vehicle-specific fuel consumption, energy input and emission values can be upgraded in an advantageous manner, and indeed when they are distributed in passenger transport to the transported passengers. The higher the effective number of passengers, the lower the passenger-specific fuel consumption and emission levels. In order to be able to calculate these passenger-specific values, knowledge of the route-specific occupancy rate is required. In order to determine this, the inventor propagates that a device be set up in the motor vehicle which is suitable for determining and communicating via a suitable data interface or keeping retrievable how many seats in the motor vehicle are occupied on which route section. The following then determines vehicle-specific, preferably in the back-end, such as the fuel consumption, the energy input, the (LCA) GHG emission, the nitrogen oxide emission or the particulate matter emission absolutely, per passenger-kilometer or per passenger and unit of time has failed.

Passenger-related fuel consumption, energy consumption and emission figures for passenger transport correspond to the fuel consumption, energy consumption and emission values of freight transport related to the transport performance (work). In order to be able to calculate these freight-specific values, knowledge of the route-specific transport performance is required. In order to determine this, the inventor propagates that a device be set up in the motor vehicle which is suitable for determining and communicating via a suitable data interface or with which payload (net) or gross load the commercial vehicle is loaded on which route section. In the following, vehicle-specific, preferably in the back-end, such as the fuel consumption, the energy input, the (LCA) GHG emission, the nitrogen oxide emission or the particulate matter emission absolute, per ton-kilometer or per ton and unit of time has failed. It may be advantageous to determine how long vehicle-specific refueling or charging will take on a case-by-case or average basis, or how that value will evolve over time. This is the case in particular with electric vehicles. The charging time can be determined by using a device capable of detecting the time of the start of charging and the time of completion of the charging of the vehicle. Usually this is a clock, preferably a clock, which can output these data (times) electronically. In the following, vehicle-specific determination is then made, preferably in the back-end, as to how long the charging time lasts in an individual case and / or on average. This determination can be made by subtracting the time of the start of charging from the time of the end of charging. Alternatively, the charging duration can be determined by detecting it directly with an electronic stopwatch and transmitting it to the back end.

In order to be able to calculate the fuel consumption, the energy input and the emissions, very specific procedures and calculation methods are required. These are based essentially on the data, which only produces the inventive method. The applicant therefore claims in particular protection for a method in which a technical value is calculated or determined according to one of the following methods or calculation methods, preferably in the back-end:

1. Identification of the refueled fuel main type in monovalent motor vehicles: by retrieving those vehicle-specific data from the vehicle file that refers to the propulsion technology (eg diesel engine, petrol engine, CNG engine, retrofitted CNG engine, LPG Drive, retrofitted LPG drive, ethanol / E85 drive, electric drive (BEV, plug-in), fuel cell / hydrogen drive (fuel-cell-car), etc. including the main force used);

2. Identification of the fuel sub-type fueled by petrol vehicles (Super E5 versus Super E10 and other Super Εχγ petrol): by using a device (knock sensor) capable of detecting the anti-knock or octane rating (octane) of a fuel, and from this knock resistance, the proportion of (bio-) ethanol in the gasoline fuel is determined and thus a distinction between Super E5, Super E10 and other gasoline (Super E _xy ) can be made. Alternatively, by manually entering the switch with and without forwarding this indication to the front-end.

3. Identification of the fuel sub-type fueled by diesel vehicles (B7 diesel, BIO diesel and other diesel Βχγ fuels): by using an in-vehicle device capable of determining the FAME content of a diesel fuel or by comparing the refueling data (Global geographic position, fuel main type) from the vehicle file with the petrol station file data related to the petrol station-specific dispensed fuel sub-types, wherein the identification of the refueling station takes place according to procedure 5. Alternatively, by manually entering the switch with and without forwarding this indication to the front-end.

4. Identification of the refueled main fuel type in bivalent and dual-fuel vehicles: by retrieving those vehicle-specific stored data and values from the vehicle file related to the propulsion technology (eg diesel / plug-in hybrid, gasoline / plug-in Hybrid, petrol / CNG drive, retrofitted bivalent gasoline / CNG drive, diesel / CNG drive, retrofitted diesel / CNG drive, diesel / LNG drive, retrofitted diesel / LNG drive, CNG / Plugln hybrid, electric drive with range extender, etc.) and / or by retrieving the refueling data reported to the back end, wherein the fuel specific tank whose level has increased defines the refueled main fuel type; Identification of the refueling station (gas station, charging station, other battery charging point) at which a motor vehicle is refueled or charged: by comparison of the global geographical data (GPS coordinates) received from a facility (GPS facility) during refueling reported and ultimately stored in the vehicle file with the global geographical data (GPS coordinates) of the gas stations stored in the gas station file; Identification of the fuel subspecies with which a motor vehicle is refueled or charged: by retrieving the refueling station-specific fuel main and fuel sub-type (or sub-type) from the refueling station file, the refueling station or charging station, at which the motor vehicle has been refueled or previously charged, is previously identified according to procedure 5 (identification of refueling station);

Determining the fueled amount of fuel: by retrieving the corresponding internal vehicle components (eg, tank sensor, fuel gauge, flow meter, electricity meter or the like) or from a vehicle-external device (eg refueling station, payment system) to the front-end and ultimately transmitted to the back-end and values stored in the vehicle file;

Determining the fuel consumption between two refueling: by subtracting the reported refueling levels at the time of commencement of refueling from the refueling levels at the time of the end of the last preceding refueling;

Determination of the distance traveled by the motor vehicle between two refueling operations: by retrieving the odometer reading from the vehicle file counted by the odometer since start-up and reported to the back-end at the time of fueling, by calling the number counted since start-up by the odometer and at the time of the last refueling the odometer reading from the vehicle file reported to the back end and subtracting the second from the first value, or by directly recording and storing the distance traveled from refueling to refueling into the vehicle file;

Determination of the route-specific fuel consumption (per km, per 100 km): by dividing the fuel / electricity consumption determined in accordance with procedure 8 by the route determined according to procedure 9;

Determining the range (e.g., km per gallon): by dividing the route determined in accordance with Procedure 9 by the fuel / power consumption determined in accordance with Procedure 8;

Determination of the seat-specific route: directly by seating-specific detection of the start of the vehicle continuously counted mileage, where seat specific sections with seat occupancy of the entire route to be subtracted or indirectly by recording the odometer at the time of occupancy of a seat by recording the odometer reading at the time a seat is vacated and by subtracting the first odometer reading from the second odometer reading;

Determining the route-specific occupancy rate: Division of the sum of all seat-specific routes determined according to procedure 12 by the route determined according to procedure 9, preferably based on the distance covered between two refuelings. Determining the route-specific fuel consumption per passenger kilometer: Division of the fuel / power consumption determined in accordance with Procedure 10 by the occupancy rate determined in accordance with Procedure 13;

Determination of the section-specific freight performance (work): Indirect recording of the odometer reading counted from the start of the commercial vehicle at the time of (partial) loading, recording of the payload (measured in kg or tons), recording of the odometer reading counted from the start of the commercial vehicle Time of (partial) discharge, subtraction of the first odometer reading from the second odometer reading, multiplying the result (expressed in kilometers) by the weight (gives the freight measured in tonne-kilometers) or direct recording by multiplying by a segment by segment the distance (measured in km) the transport weight (also gives the freight measured in tonne-kilometers); Determination of the route-specific load factor: Division of the sum of all freight services determined according to procedure 15 by the route determined according to procedure 9, preferably based on the distance covered between two refuelings. Determination of the route-specific fuel consumption per tonne-kilometer: Division of the fuel / electricity consumption determined in accordance with Procedure 10 by the degree of loading determined in accordance with Procedure 16;

Determination of fuel-specific energy content (calorific value): Except in the case of electric current, transfer of fuel-specific (lower) calorific values from directives, laws, ordinances and other government and non-governmental publications and storage of these energy contents in the fuel file;

Determination of Fuel / Electricity Specific (LCA-CC Emission: Takeover of LCA C0 ₂ Emission Values from Directives or Fuel / Electricity Manufacturing Paths from Directives, Laws, Regulations and Other Government Publications and Storage thereof the fuel-specific energy content related emission levels in the fuel file;

Determination of the route-specific (LCA-CC emission (per km): conversion of the route-specific fuel consumption of a motor vehicle determined according to procedure 10 by means of the fuel-specific calorific values determined according to procedure 18 and stored in the fuel file in a route-specific Energy consumption (calorific value consumption) and multiplication of the result with the fuel / electricity-specific (LCA) CO ₂ emission determined according to procedure 19 and likewise stored in the fuel file;

Determining the (LCA CCVEmission per passenger kilometers: Division of the calculated pursuant to procedure 20 routes specific ((in GC0 ₂ / km measured) LCA) C0 ₂ emission detected by the determined in accordance with procedure 13 occupation rate or conversion of according to Procedure 14 Route-specific fuel consumption per passenger kilometer by means of the fuel-specific calorific values determined in accordance with procedure 17 and stored in the fuel file in a route-specific energy input per passenger kilometer (calorific value consumption) and multiplying the result by the procedure determined according to procedure 19 and fuel-specific (LCA) CO ₂ emission also stored in the fuel file;

Determination of route-specific energy consumption per passenger kilometer: conversion of the route-specific fuel consumption determined per procedure 14 per passenger kilometers by means of the fuel-specific calorific values determined in accordance with procedure 17 and stored in the fuel file;

Determination of (LCA-CCVEmission per ton-kilometer: division of the route-specific (in gC0 ₂ / km measured) (LCA-) C0 ₂ emissions of a commercial vehicle determined by procedure 20 by the degree of loading determined in accordance with procedure 16 or conversion according to the procedure Mediated route-specific fuel consumption per ton-kilometer by means of the fuel-specific calorific values determined in accordance with procedure 18 and stored in the fuel file in a route-specific energy input per ton-kilometer (calorific value consumption) and multiplying the result by the procedure according to procedure 19 determined and also stored in the fuel file fuel-specific (LCA) C0 ₂ emission;

Determination of the fuel-specific exhaust gas mass: Transfer of exhaust gas values specific to origin or fuel / electricity production path (total mass flow per fuel quantity or total mass flow per calorific value) from directives, laws, ordinances and other government publications into the fuel file;

Determining the vehicle-specific exhaust gas mass: Calculation of the (stoichiometric) total exhaust gas mass from the respective fuel application with special consideration of its carbon, oxygen, hydrogen, nitrogen and sulfur content by multiplying the fuel input with the fuel-specific exhaust gas mass values from procedure 24 or Measurement of the amount of exhaust gas (total exhaust gas mass) by means that are suitable directly (total exhaust gas mass meter) or indirectly (inlet air mass meter or Flügelradanemometer taking into account the measured over a lambda sensor excess air factor) generated by the engine of a motor vehicle exhaust gas or exhaust gas mass to eat;

Determination of the route-specific total exhaust gas mass: multiplication of the fuel-specific total exhaust gas mass determined according to procedure 24 with the route-specific fuel consumption (mass, volume) determined according to procedure 10;

Determination of the nitrogen oxide mass fraction in the total exhaust gas mass flow: Continuous measurement of the (volatile) nitrogen oxide mass fraction of the total exhaust gas mass flow or continuous measurement of the (volatile) nitrogen oxide volume fraction of the total exhaust gas volumetric flow and multiplication of the two volumes with the respective densities with special consideration of exhaust gas temperature;

Determination of the route-specific nitrogen oxide emission mass: multiplication of the route-specific total exhaust gas mass determined according to procedure 26 with the average nitrogen oxide mass fraction determined according to procedure 27;

Determining the route-specific nitrogen oxide emission mass per passenger kilometer: Division of the route-specific nitrogen oxide emission mass determined according to procedure 28 by the route-specific occupancy rate ascertained in accordance with procedure 13;

Determination of the nitrogen oxide emission mass per tonne-kilometer: Division of the route-specific nitrogen oxide emission mass determined according to Procedure 28 by the route-specific loading level determined in accordance with Procedure 16;

Determination of the Particulate Matter Mass in the Exhaust Gas: Continuous measurement of the volatile particulate mass fraction in the exhaust gas and formation of an average value or acceptance of corresponding standard values, typical values or averages from directives, laws, regulations and other government publications into the fuel file;

32. Determination of the route-specific particulate matter emission mass: multiplication of the route-specific total exhaust gas mass determined in accordance with procedure 26 with the particulate mass fraction determined according to procedure 31;

33. Determination of the route-specific fine dust emission mass per passenger kilometer: division of the route-specific particulate matter emission mass determined according to procedure 32 by the route-specific occupancy rate determined in accordance with procedure 13;

34. Determination of the particulate matter emission mass per tonne-kilometer: Division of the route-specific particulate matter emission mass determined in accordance with Procedure 32 by the route-specific loading level determined in accordance with Procedure 15.

The inventive method and its developments disclosed herein relate to the LCA-C0 ₂ equivalents in terms of GHG emission. However, it is also possible to use the method to determine only the stoichiometric CO ₂ emission values. For this purpose, instead of the fuel-specific LCA-GHG emission values, only the stoichiometric GHG emission values must be entered in the fuel database. The calculation of the values then takes place as in the calculation of the LCA-THG emission values (see above).

As interesting and advantageous is the knowledge of motor vehicle-specific fuel consumption, energy input and emission values, even more advantageous is the knowledge of aggregated values. For example, the average values determined for all passenger cars are significantly more informative than vehicle-specific values - which, in turn, are necessary in order to arrive at the average values at all. It will be understood that other forms of data aggregation may be obvious to one of ordinary skill in the art having the benefit of this invention. These should also be protected, in particular the data aggregation according to a) type of motor vehicle, b) motor vehicle model, c) engine type, d) engine model, e) manufacturer, f) motor vehicle class (eg upper class, middle class etc.), g) other motor vehicle segment, h) customer segment, i) district, j) city, k) state, i) drive type / technology (diesel, petrol, CNG, LPG, electric, hydrogen etc.), m) main fuel type (including electricity), n) fuel and electricity subspecies, o) period, p) period (eg minute, hour, day, week, month, quarter, year or a fraction of these periods), q) distance, r) Mileage, s) ton-kilometers, t) passenger-kilometers, u) according to other technical characteristics and criteria.

Highly interesting and highly explosive, and therefore advantageous, is the determination of the difference between the official manufacturer data obtained on the occasion of the type approval and the values obtained in everyday use with regard to all the values considered above, preferably with regard to fuel consumption, energy input and various emissions has been referred to in detail above and therefore should not be re-enumerated. This is especially preferred for aggregated values.

The data and values ascertained above can be communicated with or without intermediate storage via communication network (Internet, mobile radio, cable network or the like) or by post letter to a plurality of addressees, namely in each case at least: a) a driver of a specific vehicle, b) a keeper of a c) a tax authority, d) a municipal authority, e) a transport authority such as the Federal Motor Transport Authority, f) an environmental authority, g) a vehicle manufacturer, h) a vehicle tuner, i) a vehicle Dealer, j) an operator of an internet community, k) a leasing company, i) an insurance Company, m) a fuel manufacturer, n) a power generator, o) a tire manufacturer, p) a research institute, q) an environmental institute, r) a GO, s) a company, t) an NGO, u) a other interested party.

Finally, the fuel or energy input values and / or emission values determined by the method according to the invention can be ascertained, called up and / or utilized not only for road vehicles, but also for other motor vehicles, such as e.g. Motor vehicles that do not move regularly on roads (agricultural and forestry vehicles, construction site vehicles, etc.). In addition come as objects of the analysis of the invention motor boats, ships, aircraft, helicopters, locomotives and other trains, etc.) into consideration.

The system according to the invention consists in the basic version of the invention, which is described in the independent claim 56, first of at least one electronic component of a vehicle. This component is connected to an electronic front-end. The at least one electronic component supplies certain operating data of the vehicle, preferably odometer readings, tank levels (or battery charge states) and / or fuel / power consumption quantities, electronically to the front end.

In one embodiment variant, the electronic component comprises a device installed in the motor vehicle or a corresponding subsystem (odometer or the like) which is suitable for detecting a driving route covered by a road motor vehicle and transmitting this value electronically to the front end. The transmission to the front-end takes place via a suitable interface, preferably via a vehicle-internal device for recording operating data, particularly preferably via an on-board vehicle diagnostic (OBD) device and in particular via an OBD2 device.

In a further advantageous embodiment, the electronic component comprises a device (fuel sensor, engine control or the like) which is suitable to detect in the road vehicle, which main fuel types a road vehicle has used or consumed on a driving route and this value electronically to the front -End to transfer. The transmission to the front end takes place via a suitable interface, preferably via a vehicle-internal device for recording operating data, particularly preferably via an on-board vehicle diagnostic (OBD) device and in particular via an OBD2 device. If the back end (see below) has access to a vehicle file / database in which the main fuel type is stored (for example, when registering the vehicle), this vehicle can be omitted from collecting this part of the data record ,

In an even more advantageous development, the electronic component comprises a device (fuel sensor, engine control or the like) which is suitable for detecting in the road vehicle which fuel subsets a road vehicle has used or consumed on a driving route and electronically forwards this value to the front -End transfer (eg by a knock sensor). The transmission to the front-end takes place via a suitable interface, preferably via a vehicle-internal device for recording operating data, particularly preferably via an on-board vehicle diagnostic (OBD) device and in particular via an OBD2 device.

In a further advantageous embodiment, the electronic component comprises a device (float, tank sensor, level gauge, microcontroller, voltmeter or the like), which is suitable to detect in the road vehicle, which level of the tank and / or Have the batteries of a road vehicle, and electronically transmit this value to the front end. The transmission to the front-end takes place via a suitable interface, preferably via a vehicle-internal device for recording operating data, particularly preferably via an on-board vehicle diagnostic (OBD) device and in particular via an OBD2 device.

In a further advantageous development, the electronic component comprises a device (flow meter, fuel, electricity meter or the like), which is suitable to detect in the road vehicle, which fuel or electricity consumption has a road vehicle on a specific route, and this value electronically to transmit the front end. The transmission to the front-end takes place via a suitable interface, preferably via a vehicle-internal device for recording operating data, particularly preferably via an on-board vehicle diagnostic (OBD) device and in particular via an OBD2 device.

The electronic front-end is adapted to obtain, read, electronically time-stamp, and continuously provide vehicle-specific data from the electronic component of the vehicle, such operational data or a version thereof, and / or additional data generated by itself or by peripheral devices or store them in an internal data store and later batch them. The transmission of the data preferably takes place wirelessly via a communication network to a back-end. The front-end is an electronic device that i.a. may be integrated into a motor vehicle computer system or a special adapter. This computer system may be a system that is independent of the OBD system of the vehicle as well as the OBD system itself. Thus, the computer system integrated into the vehicle can not be included in the vehicle diagnostic system integrated and connected to the data transmission only to the vehicle diagnostic system of the motor vehicle. The front-end can also have an OBD interface module, OBD memory module, OBD adapter, OBD2 adapter, client computer device, PC, laptop, PDA, telephone, internet enabled phone, wireless communication, WiFi / WLAN enabled Devices, UWB hub, smartphone, navigation system, computer system, peripheral connection module, display and other front-end device with access to an electronic component of a vehicle. The front end is connected to at least one electronic component of a vehicle. Preferably, this at least one component is an electronic vehicle sensor or an electronic vehicle system. Particularly preferably, this at least one component is an on-board vehicle diagnostic system (OBD system).

When the front-end continuously passes on the data received from the at least one vehicle sensor / vehicle system / OBD system, it may be a forwarding to a front-end external data store or a handover to a device that is suitable to hand over - transmit data as a sender over an air interface to other facilities (eg a switching device) or to a communication network.

If the front-end itself has no data storage, it is possible that an external data storage, such as a chip (card memory), a USB stick or the like, via an appropriate interface (slot) is plugged into the front-end. If necessary, the external data memory is removed from the front-end and plugged into a PC, laptop, a user communication terminal or the like for data transmission and data analysis. Calculations and / or analysis of the transmitted operating data of the vehicle may be made in the PC, in the laptop, in the user communications terminal or in the like devices, or these devices may pass them on to a back end, which then performs the vehicle-specific calculations and data analysis , If the front-end passes the operating data continuously to a front-end external data storage, the data can be read from the external storage batch-wise, continuously or semi-continuously as required, with or without separation of the external data storage from the front-end storage. End.

If the front-end itself has an internal data memory, the entire front-end can be removed from the vehicle if necessary and plugged into a PC, laptop, user communication terminal or the like for data transmission and data analysis. Calculations and / or analysis of the transmitted operating data of the vehicle may be made in the PC, in the laptop, in the user communications terminal or in the like devices, or these devices may forward them to a back end, which then performs the calculations and data analysis.

However, it is also possible that the front end remains in the vehicle, and vehicle-specific operating data are transferred from the internal data memory of the front-end to an external data memory and the forwarding of the data is carried out as described above for the external data memory.

Finally, according to a preferred development, it is possible for the front-end to be suitable for communicating with the outside world via a suitable interface, preferably via a standardized interface. In this case, the communication may be such that the front-end transmits the vehicle-specific operating data directly to a back-end via a communication network, which performs the calculations and the data analysis.

However, the communication can also take place in such a way that the front end transmits the data indirectly to the back end, namely first to a suitable switching device. This switching device then assumes the forwarding of the data to the back-end, preferably by the interposition or use of an existing communication work such as the Internet, a mobile network, a cable network, a telephone network or the like.

Preferably, the front-end is associated with a particular motor vehicle so that the back-end vehicle operating data transmitted from the front-end can be uniquely assigned to a particular vehicle. Particularly preferably, this assignment takes place via a unique identification number.

The front-end preferably has an OBD connector, more preferably via an OBD2 connector and in particular via a 16-pin OBD2 male connector. The advantage of this embodiment is that almost any vehicle can be connected to the system according to the invention without further technical effort, because almost every vehicle has an OBD2 system, which by definition has an OBD2 socket (in mother form). It goes without saying that the front-end can also include a connector, if necessary, which represents the successor of the OBD2 connector.

In an advantageous embodiment of the system according to the invention, the front end is an OBD adapter, preferably an OBD2 adapter. Moreover, if this OBD2 adapter is advantageously equipped with an OBD2 plug, more preferably with a father plug, it can easily be plugged into any OBD2 socket of almost any motor vehicle, enabling almost any motor vehicle to become part of the system of the present invention become.

In a particularly advantageous development of the invention, the front end (the OBD2 adapter) has a suitable air interface, via which it can transmit data wirelessly to a switching center. direction transfers. The advantage is that in the "installation" of the adapter no additional cables must be laid, which facilitates the implementation of the system according to the invention.

In a further development, the air interface of the front-end is adapted to transmit the data, bypassing the switching device directly to a communication network. This is e.g. then the case when the front end is equipped with a mobile interface, a SIM card slot and a SIM card. The mobile radio interface can also already be installed as firmware in the hardware of the front-end. The saving of the switching device reduces the technical complexity in an advantageous manner.

If the front-end or the OBD2 adapter can execute (possibly freely programmable) work instructions, this is advantageous for the operator of the system according to the invention. In addition to the original functions, it is then possible for the front-end to transmit further or other functions, in particular those which change over time or which are added later. In order to play these work instructions on the front-end, the presence of corresponding components is a prerequisite, in particular those components that make a corresponding communication with the front-end and the storage of work instructions or corresponding software programs possible. It is therefore advantageous to have an embodiment variant of the system according to the invention, in which the front-end comprises a selection of the components microprocessor, program memory, data memory, a Bluetooth chip. The OBD2 adapter (the front end) preferably additionally has a mobile radio transmitting / receiving module (modem) including mobile radio antenna, a WiFi / WLAN interface, an interface (slot) for memory extensions, a receiver and / or or an evaluation unit for global positioning data (eg NAVSTA GPS, GLONASS GPS, GALILEO GPS, BEIDOU GPS), a rechargeable battery (battery) and a power management system. The latter makes it possible to remove the OBD2 adapter (the front end) from the OBD system of the vehicle - from which it is supplied with power - without losing memory contents and therefore data and / or software programs / work instructions. The implementation of the method is also possible with front ends, the technical structure is kept simpler.

It is an advantage if the front-end not only records odometer readings, tank levels and fuel consumption, but also other data and values. In an advantageous further development of the system according to the invention, the front-end is therefore suitable for detecting a selection of the following values and transmitting them to the switching center or via the communication network to the back-end: distance traveled since commissioning, distance covered since last or any previous one Refueling, refueled fuel types or charged types of electricity, route-specific consumed fuel / electricity types, refueled energy or fuel. Fuel quantities, route-specific consumed energy or. Fuel quantities, seat specific seats, route specific transported number of passengers, route specific transported weight (gross, tare, net), absolute exhaust gas quantity (mass, volume), total exhaust gas flow, total exhaust mass flow, absolute nitrogen oxide emission quantities (volume, mass) , Nitrogen oxide emissions in a relative quota value, proportion of nitrogen oxide emission amount in the total exhaust gas amount, proportion of nitrogen oxide emission in the total exhaust gas volume flow, proportion of nitrogen oxide emission in the total exhaust gas mass flow, absolute particulate matter emission quantity (volume, mass), particulate matter emission in one relative quota value, fraction of particulate matter emission amount in total exhaust gas quantity, proportion of particulate matter emission in total exhaust gas volumetric flow, proportion of particulate matter emission in total exhaust gas mass flow, global geographical vehicle position, global geographical vehicle position in refueling, Nitric oxide emission, particulate matter emission, nitrous oxide emission, Sulfur dioxide emission, carbon monoxide Emission, Noise emission, Oil level, Oil consumption, Tire wear, Tire inflation pressure, Tank level, Tank level at start of refueling, Tank level at completion of refueling, Tank range, Battery level, Battery level at start of charge, Battery level at start of charge, Battery range, Vehicle weight, Vehicle load, Vehicle load per leg, seat occupancy, seat occupancy per leg, vehicle angle to the longitudinal axis, vehicle angle to the transverse axis, airbag tripping, cooling water temperature, starting behavior, emergency signal and other relevant values for professionals.

In addition to the components that a host system must have in order to be able to operate as intended (in this regard, reference is made to the state of the art), the backend comprises at least one file or database with vehicle-specific data (vehicle file / data). Database) and at least one file or database with fuel-specific data (fuel file / database). Alternatively, the back-end is at least temporarily connected to one or more components of a data-sharing system that includes a vehicle file / database when no such is operated in the back-end and additionally a fuel file / database, if the backend does not have these too. In these cases, the parts of the system according to the invention which are located outside the actual back-end (eg the two files / databases listed above and possibly a third file / database "petrol stations") are considered to belong to the back-end in the sense of this publication The fuel-specific (including current type-specific) data of the fuel file / database contain, among other things, relevant data on the greenhouse gas emission and on the energy content (calorific value) of at least one fuel or at least one type of electricity.

The back-end is suitable for receiving and processing vehicle-specific data from the communications network. The back-end or one or more components of a data link system, with which the back-end is at least temporarily connected, are also suitable for detecting or calculating a travel distance covered by the road vehicle. Moreover, the back-end or one or more components of a data link system to which the back-end is at least temporarily connected may be capable of determining or calculating which fuel types and / or types of power the road vehicle is consuming on that route Has. In addition, the back-end or one or more components of a data link system to which the back-end is at least temporarily connected are capable of determining or calculating which fuel and / or electricity quantities the road vehicle has consumed on that route. Finally, the back-end is capable of calculating from the traveled distance of the road vehicle, the fuel or power consumed on this route, the fuel and / or electricity consumed on this route and the fuel / power type specific GHG emissions which GHG emission quantities (masses, volumes) the road vehicle has emitted on the traveled route into the earth's atmosphere.

Preferably, the back-end is adapted to calculate the GHG emission amounts from the input energy used and the fuel-specific (GHG) emission amounts per unit of energy, the amounts of energy used being the provision of fuel-specific heating values in the fuel database and the multiplication of these calorific values with the fuel consumption quantities.

The back-end is capable of receiving, processing and storing data via a suitable interface from a communication network. The back-end can be a data center with CPU, data storage, data analysis program, web server, data acquisition module, data transfer module and suitable software, as well as a data network system, a server with one suitable software application, a server network, a host system with data processing subsystem, a suitable user terminal (PC, laptop or the like) with suitable software applications or the like. It may include a web server and / or other gateway systems. In this regard, reference is made to the prior art.

The back-end includes at least two additional files / databases, in addition to the parts and files required for normal operation, namely a file / database of vehicle-specific data (vehicle file / database) and a file / database of fuel-specific data ( / database) fuel file. In addition, the back-end preferably additionally comprises at least one third file, namely one with filling station-specific data (filling station file / database).

Based on the various system elements, the back-end is suitable for detecting the distance traveled by a motor vehicle and the type of fuel or the type of current that the motor vehicle has used or consumed on this route. In addition, the back-end is suitable for determining or calculating the quantities of fuel (amounts of electricity) that the motor vehicle consumed on this route. Namely, these data are transmitted to the backend or the backend is capable of calculating these values from the transmitted data. Further, the back-end is adapted to convert the route-specific quantitative fuel consumption into a route-specific use of energy by consulting the fuel-specific energy contents (calorific values) stored in the fuel file / database. As part of the inventive system, the back-end is also suitable from the traveled distance of the motor vehicle, the fuel / power types used on this route, the route-specific energy input amounts used and the fuel / power type specific (LCA -) To determine or calculate GHG emissions, which (LCA) GHG emission quantities (masses, volumes) the motor vehicle has emitted on the traveled route into the earth's atmosphere.

The distance traveled by the motor vehicle is the reference frame for all quota values relating to one kilometer or 100 kilometers. Knowing this is necessary for every comparison between motor vehicles. Consequently, it is advantageous if the system according to the invention comprises a back-end device (software application, program) which is suitable for detecting or calculating which route the vehicle is traveling between the last and the penultimate refueling / charging or between completed the last and any previous fueling / recharge.

The data transmitted to the back end includes vehicle-specific information on the fuel consumption (including power consumption) of at least one road vehicle, preferably information about its route-specific fuel consumption. Alternatively, the system according to the invention can also determine these fuel consumption values from other data transmitted to the back end, e.g. from the tank levels. It goes without saying that, in this context, the information on fuel consumption can be replaced by information on energy inputs. So it is e.g. It is possible to convert fuel consumptions into energy inputs or energy consumption already in the OBD system, in the front-end or in the switching center from quantitative fuel consumption. In this case, only the calculated energy inputs are transferred to the backend.

In an advantageous further development of the inventive system, the back-end is suitable, the determined route-specific values of a road vehicle in other vehicle or track-specific quotas (eg in fuel consumption / 100 km, Energieeinsatzmen- ge / km, energy input / year, (LCA) GHG emissions in gC0 ₂ -equivalent / km, C0 ₂ - emissions / month, C0 ₂ emissions / year, etc.) using simple mathematical rules.

In an advantageous development, the back-end comprises a device (software application, program) which is suitable for calculating which amounts of energy a road vehicle has used on a route, preferably from the vehicle-specific data transmitted to the back-end, particularly preferably by merging vehicle-specific data transmitted to the back-end (for example, a liter indication for the filling quantity and a mileage specification for the driving route), vehicle-specific data from the vehicle database (for example, fuel main type diesel) and Fuel-specific data from the fuel file (eg the calorific value of Diesel of subspecies Diesel B7). With a liter specification of eg 50 liters, a kilometer specification of 900 km and a lower calorific value of 9.9 kWh _H i / liter, this results in an energy input of 495 kWh _H i to 900 km and thus an energy input of 55 kWh _H i per 100 km or 0.55 kWh _H i / km.

For comparison purposes it is advantageous to know not only the fuel consumption and emissions associated with a particular route, but also specific quota values such as fuel consumption / 100 km or CO ₂ emission / km. In a further development, the back-end therefore comprises a device (software application, program) which is suitable for converting the determined route-specific fuel, energy or (LCA) GHG emission values of a road motor vehicle into other vehicle-specific quota values ( eg in fuel consumption / 100 km, energy use per km, energy consumption per year, energy consumption over the entire vehicle lifetime, (LCA) GHG emissions in gC0 _2- equivalent / km, C0 ₂ emissions per day, C0 ₂ emissions per week, C0 ₂ emissions per month, CO ₂ emissions per year, CO ₂ emissions over the entire vehicle service life, etc.).

In a further advantageous embodiment variant, the back-end device (software application, program), which is suitable from the traveled route of a road vehicle, the fuel used on this route fuel or electricity, the consumed route-specific amounts of energy and the Determine fuel / power-specific (LCA) GHG emissions and calculate what (LCA) GHG emission levels (masses, volumes) a road-going vehicle has emitted into the Earth's atmosphere over the distance traveled. Continuing the example given above with an LCA-THG emission of, for example, 332.1 gC0 ₂ -eq / kWh _Hi for diesel B7 results in an LCA-THG emission of 0.55 kWh _Hi / km x 332.1 gC0 ₂ -eq / kWh _Hi = 182.7 gC0 ₂ -eq / km.

It goes without saying that such a system or the back-end is suitable in all variants, the investigation and / or calculation results (of the back-end) for at least one user visible, for at least one software application available or in another way, eg by simply expressing the results, by providing Internet access to the files of the back-end, by granting appropriate access permissions, by sending e-mails or by other common or proprietary forms of communication.

As described above, the backend can be a server with a suitable software application or even a web server, a database, a data center with suitable software, a data network system, a user terminal with a suitable software application or the like. For the design of such computer systems, reference is made to the state of the corresponding technology. The back-end is suitable for receiving data, preferably vehicle-specific data, in particular data relating to a route traveled by the vehicle and data on refueling of the motor vehicle, via a suitable interface from the communication network and before or after a calculation or evaluation in at least one vehicle-specific file or database (vehicle file, vehicle database) store, store and keep retrievable for further analysis or calculations.

The backend is also suitable for keeping at least one file or database with fuel-specific data (fuel file, fuel database).

In particular, it is advantageous if a device (software application, program) is present in the back-end which is suitable for detecting or calculating vehicle-specific data from the vehicle-specific data transmitted to the back end, with which tank - / Batterieladezuständen started the refueling or charging and with which tank / battery charging conditions, the refueling or charging were completed and / or with what amounts of energy (fuel quantities, amounts of electricity) fueled or recharged a motor vehicle.

Furthermore, the back-end is suitable for calculating, storing and / or exporting from the transmitted vehicle-specific data vehicle-specific at least one of the following technical values: the emission of (LCA) C0 ₂ equivalents in one absolute amount, the (LCA) C0 ₂ emission amount per trip, the (LCA-) C0 ₂ emission amount per period (day, week, month, year, vehicle lifetime, etc.), the (LCA) C0 ₂ emission amount between two fueling operations, the emission of (LCA-) C0 ₂ equivalents in a relative quota, the (LCA-) C0 ₂ emission amount per km of travel, the (LCA-) C0 ₂ emission amount per 100 km of driving distance (LCA -) C0 ₂ emission amount per fuel quantity (kilogram, ton, liter, gallon), the (LCA) C0 ₂ emission amount per unit of energy (MJ, kWh), the emission of (LCA-) C0 ₂ equivalents in other technical representations or values. The knowledge of these values is useful and advantageous, in part even condition, for the determination of further values derived therefrom.

In addition, the back-end is suitable for evaluating the vehicle-specific data transmitted from the communication network for fuel consumption (power consumption) and converting it into quota values. Particularly preferably, the back-end is suitable for calculating the route-specific energy input of at least one motor vehicle from these data. Alternatively, it is appropriate to calculate the energy input values from other vehicle-specific data transmitted to the back end.

In an advantageous development, the back-end is suitably made of the route-specific energy input and the fuel-specific (including current-type-specific) data of the fuel file or the fuel database, preferably with the involvement of different energy-specific (on energy unit related) (LCA) GHG emission values of the fuels to calculate the range-specific (LCA) GHG emission levels, or the (LCA) GHG emission volumes and / or the (LCA) GHG emission masses, respectively single motor vehicle has emitted into the environment (earth's atmosphere).

In an advantageous development, the back-end is suitable for converting the determined route-specific energy input and / or (LCA) GHG emission quantities of the considered road vehicle into other vehicle-specific quota values, for example, the fuel consumption per 100 km, the energy input of a Year, the (LCA) GHG emissions in gC0 ₂ equivalent, C0 ₂ emissions per month or other common quota values.

In one embodiment variant, the back-end is suitable for making the vehicle-specific calculation results and / or values aggregated from these results available to at least one user and / or for at least one software application (software program). The Back-end may also be suitable for printing out its results as a list, transmitting it to interested parties via the communication network (eg Internet), making it generally available or otherwise usable.

In addition, it is advantageous to know the fuel subspecies or current subspecies, with which a motor vehicle was refueled or charged. The Applicant therefore claims protection for a back-end device (software application, program) which is suitable for matching fueling data transmitted to the back-end, in particular refueling data relating to the main fuel types, and the in-line fueling system The gas station file of the back-end stored gas station-specific fuel subspecies to identify the fuel subsets with which the motor vehicle was refueled or charged

A particularly advantageous development of the inventive system is given when a back-end device (gas station file / database) is present, which can store information on the GPS position of gas stations and preferably gas station-specific information about the dispensed by the gas stations Fuel main types and fuel subspecies. By using this information, e.g. the (LCA) GHG emission can be determined more precisely. In this particularly advantageous embodiment variant, the system according to the invention in the back-end comprises a device (filling station file) which is suitable to receive, store and retrieve petrol station or charging point-specific data, preferably information on the global geographical position of the individual petrol stations to keep. Particularly preferably, this facility (petrol station file) includes petrol station-specific information on the fuel sub-types dispensed at the individual petrol station, e.g. the origin / type of diesel fuel dispensed, origin / type of biodiesel delivered, actual mixture ratio for diesel / biodiesel blends (B7), origin / type of petrol dispensed, origin / type of bioethanol dispensed, actual blending ratio for gasoline blends and bioethanol, origin / type of CNG, origin / type of bio methane, actual mixing ratio for mixtures of CNG and bio methane, origin / type of LNG, origin / type of LBM (Liquefied BioMethane), actual mixing ratio for mixtures of LNG and LBM , Origin / type of LPG, origin / type of synthetic methane (SynMethans), actual mixing ratio for mixtures of SynMethan of different origin or type, origin / type of hydrogen, actual mixing ratio for mixtures of hydrogen of different origin or species, origin / species of current, actual mixing ratio at mis Electricity from different sources and other information on other fuels.

In order to identify the filling station / charging station at which a motor vehicle has been refueled or at which it has been charged with electricity, it is advantageous if an adjustment can take place between the refueling location reported from the motor vehicle and the locations at which a refueling station or refueling station is located . a charging station is. It is therefore also requested protection for a back-end device that (software application, program), which is suitable, by a comparison between the transmitted from the front-end global geographic position (GPS coordinates) of the vehicle refueling or . Charging and the global geographical positions (GPS coordinates) of the gas stations or charging points stored in the gas station file of the back-end to identify the gas station where the vehicle was refueled or charged.

Finally, it is advantageous if the back-end and thus the system according to the invention has a device which is suitable from the route-specifically used fuel subspecies, the route-specifically consumed energy or fuel quantities and the fuel-specific sub-types to calculate energy unit related (LCA) GHG emissions which (LCA) ) GHG emission levels the motor vehicle on the distance covered, per unit time, per period, per km, per 100 km, per trip, since commissioning, based on a passenger kilometer or based on one ton-kilometer has emitted into the earth's atmosphere.

Not least for the environment, it is advantageous to publish the results determined by or in the backend. In an advantageous exemplary embodiment, the system according to the invention therefore comprises a back-end device (software application, program) which is suitable for viewing the determination and / or calculation results of the back-end for at least one user or for at least one software application or otherwise usable.

In a further development of the basic version, the system according to the invention, in addition to the relevant sensors and systems of the motor vehicle, the front-end and the back-end further consists of a switching device which is suitable to receive data from the front-end via a suitable interface and this or forward a version thereof with and without caching to a back end via a communications network (Internet, telephone network, cellular network, cable network or the like). The switch uses front-end interface technology with standard formats for local data reception, preferably USB format for data transmission via cable, and preferably Bluetooth format, WiFi / WLAN format, 802.11b format for data transmission via the air interface or similar.

The switching device of the system according to the invention is preferably a device with access to a wide communication network (Internet, mobile radio, cable network, telephone network or the like). If the front end does not have such wide access, it can still connect to a communication network when connected to the switch locally. Such a construction reduces the technical complexity, in particular the technical effort that must be operated for the front-end.

In an advantageous embodiment of the invention, the switching device is a smartphone, preferably an Internet-enabled smartphone. This usually has the ability to communicate via a Bluetooth and / or WiFi / WLAN interface, which further simplifies the implementation of the front-end in the motor vehicle and its subsequent communication with the switching device.

In an advantageous embodiment, the smartphone is suitable to initialize the front-end or the OBD2 adapter after downloading a special app via Bluetooth or WiFi / WLAN and to load this with a software application (adapter app). This adapter app in turn is suitable to capture by a special programmed work instructions covered by the motor vehicle between two refueling route or odometer readings at the place of refueling and refueling data (tank level at the beginning of refueling, tank level at the end of refueling and / or capacity and in electric and so-called hydride vehicles, which have at least 2 drive technologies, one of which is mostly an electric drive, also the state of charge of the battery at the beginning of charging and the state of charge at the end of the charging and / or the charged amount of electricity). Preferably, the software application (adapter app) loaded by the smartphone on the front-end or on the OBD2 adapter is suitable for enabling the front-end to store the data detected by the front-end in the front-end (between -)save. Particularly preferably, the front end is capable after the application of the software application (adapter app) to communicate with the smartphone, with which the initialization was performed, while data transfer. In a particularly advantageous embodiment variant, the front-end is suitable for wirelessly communicating with the smartphone via Bluetooth and / or WiFi / WLAN.

The fuel file / database is suitable for detecting the different characteristics of the various fuels (main fuel types and fuel sub-types) and retrievable in the form of fuel master data. With regard to the invention, the fuel-specific master data include, in particular, technical data such as the energy content / calorific value, the sales unit (volume, mass or energy content / calorific value), the energy-specific stoichiometric GHG emission quota, the energy-specific LCA-GHG Quote, the density, the octane value and other technical data.

From the fuel subspecies average values can be determined for the superordinate main fuel type, which allow an approximate determination of the sought parameters fuel consumption, energy input and (LCA) GHG emission. The determination of the average values can be carried out weighted, that is, the fuel subspecies can enter with their sales shares in the respective average calculation. Alternatively, the backend may also retrieve these values from other data transmitted to the backend, e.g. by putting fuel quantities into relation to energy quantities. If data on fuel consumption and not data on energy inputs or energy consumption are received at the back-end, a special evaluation program of the back-end (the algorithm according to the invention) calculates the vehicle and fuel consumption or calorific values from the fuel consumption data Route-specific energy input or energy consumption.

The fuel file / database according to the invention is characterized in that the fuel-specific (including power-type-specific) data of the fuel file / database information on the (LCA) emission of at least one fuel or at least one type of electricity preferably, information on energy-specific (energy-related) (LCA) GHG emission of a fuel / stream type. Alternatively, the back-end may also determine these fuel-specific energy-related (LCA) GHG emission values from other fuel-specific data, e.g. by relating emission levels to energy input quantities.

In an advantageous development or a variant embodiment, the fuel file / database is particularly suitable for technical properties and characteristics, in particular (LCA) CO ₂ emission values, of individual main fuel types (eg gasoline, diesel, kerosene, CNG, LNG, LPG, methanol, electricity, hydrogen, etc.) and / or individual fuel sub-types (eg diesel of different origin, biodiesel of different origin, various mixtures of diesel and bio-diesel, petrol from different sources, bioethanol of different origin, various mixtures of gasoline and bioethanol , CNG of different origin, BioMethane of different origin, various mixtures of CNG and BioMethan, LNG of different origin, LBM (Liquefied BioMethane) of different origin, various mixtures of LNG and LBM, LPG of different origin, synthetic methane (SynMethan) of different origin, various mixtures SynMethane differs of origin, hydrogen of different origin, various mixtures of hydrogen of different origin, electricity of different origin, various mixtures of electricity of different origin, other fuels of different origin, etc.) to receive via a suitable data interface to store and retrievable.

The fuel file / database may be maintained in the front-end, in the switch (smartphone), in the back-end, or in any other device that is at least temporarily in contact with the back-end. End is connected. Although the data can not change per fuel subspecies, but overall, more or less often, and therefore more or less often a data update needs to be made (theoretically, any vehicle that uses a particular fuel main species can be associated with any one at any given time Fuel Subtype fueled), it is less expensive and therefore advantageous to run the fuel file / database centrally in the back-end rather than decentralized in the front-ends or in the switching devices or smartphones.

The vehicle file / database is suitable for detecting the different features of the various vehicles connected to the system according to the invention (vehicle master data). This master data may include details of the vehicle owner (eg ID number, address, communication data, age, gender, profession, business line, legal form, preferred fuel subspecies, etc.), vehicle (year of construction, commissioning, make, model, engine, Main fuel type, weight, vehicle class, vehicle ID, check number for vehicle ID, other vehicle data from the vehicle registration card, performance, number of passengers, other vehicle data), to the front-end (ID, year of manufacture, previous use, software -Release, owner, owner), to insure the vehicle (class, classification, etc.), to the drivers (eg ID number, address, communication data, age, sex, profession, business line, legal form, preferred fuel subspecies, etc.) , taxation (vehicle tax, energy tax, VAT), purchase premiums, error messages, repairs, workshop stays, TÜV inspections, TÜV expiration date, accidents, etc. etc.

In a preferred embodiment variant, the vehicle file / database comprises not only the vehicle master data but also the data records from which the actual fuel consumption, the actual energy input and the actual (LCA) GHG emission are determined (raw data records) and / or the data processed by the algorithm according to the invention finished, supplemented to certain data records.

The petrol station file / database is suitable for detecting the different features of the various filling stations, filling stations and / or charging stations (petrol station master data). In a preferred embodiment variant, the refueling station file / database comprises, in addition to the refueling station master data, data relating to the main fuel types dispensed by the refueling stations and / or technical data relating to the fuel sub-types dispensed by the refueling stations. With regard to the invention, the refueling station master data include, in particular, the GPS coordinates of the refueling stations, via which the method according to the invention identifies the individual refueling station, the main fuel types dispensed from the refueling stations, the fuel subtypes that are dispensed and the times when a gas station changes from one fuel subspecies to another.

The gas station file / database may be maintained in the front-end, in the switch (smartphone), in the back-end, or in any other device that is at least temporarily connected to the back-end. Since the data is not seen per gas station in total but constantly changing and therefore constantly a data update must be made (theoretically, each vehicle can refuel at each gas station), it is less expensive and therefore advantageous, the gas station file / database centrally in Backend instead of decentralized in the front-ends or in the switching devices or smartphones.

By constantly updating the petrol station file / database, it is always known which petrol station dispenses which main fuel types and / or fuel sub-types or which petrol station has delivered which main fuel types and / or fuel sub-types at what times. In particular, In particular, even if the fuel subsets are detected, including electric power, this file / database can take on a larger scale. After all, at the beginning of May 2016 alone in Germany, in addition to approx. 14,500 conventional filling stations and approx. 920 gas stations more than 20,000 charging stations for electric cars, with the number of charging stations to increase to several hundred thousand. If up to 100 different fuel sub-types are run for these gas stations, the volume of data can reach volumes that are too large for front-ends or exchanges.

Other developments and variants of the system

In a further advantageous embodiment, the functions of the front-end and the switching device are fully or partially integrated in a device. This is the case in particular if the front end has all the modules or components required for this, ie it can also communicate accordingly (see above). The communication then no longer takes place via an intermediary switching device but via an internal "switching device" which is a communication module, which may be a module which is suitable for communication with a mobile radio network or a module which is suitable for communication with the Internet.

It may be even more advantageous if the functions of the front-end, the switching device and a part of the functions of the back-end are integrated in a single device. The evaluation of the data then takes place in the vehicle. The evaluation results are sent in this case via communication network to the users. It is understood that the integration of the functions can be made only in the front-end, since the connection to the OBD system of the vehicle is a prerequisite. As long as the OBD system itself does not have a suitable air interface, the inevitable connection is made via connectors, namely via the maternal socket of the OBD system and the paternal OBD connector of the front-end. In order to be able to perform this integration of the functions in only one device, namely in the front end, this must be suitable for this purpose. For the design of the hardware and software requirements, reference is made to the relevant state of the art.

In one embodiment variant, the system according to the invention requires the GPS position of the vehicle at the time of refueling or charging. It is advantageous if these data are provided by a vehicle-owned component. Therefore, the applicant also claims protection for a system in the development that it includes a vehicle-internal component (position sensor, GPS / GLONASS / GALILEO / BEIDOU receiving and evaluation device or the like), which is suitable, the global To capture the geographical position (GPS position) of the road vehicle and electronically transmitted to the front-end directly or indirectly (eg via the on-board diagnostic system).

In the event that the vehicle does not have such a component, it is advantageous if these data are provided by a vehicle-external component. Such an external component may be a position sensor, navigation device, N AVSTA GPS / GLONASS / G ALI LEO / DOU receiver and evaluation device or the like. The applicant therefore also claims protection for a further embodiment of the system according to the invention comprising a vehicle-external component (position sensor, navigation device, NAVSTAR GPS / GLONASS / GALILEO / BEIDOU reception and evaluation device or the like) as appropriate is to capture the global geographical position (GPS position) of the road vehicle and electronically transmitted to the front-end directly or indirectly (eg via the on-board diagnostic system). However, it is also possible to integrate the module that determines the GPS position into the front end. The technical effort is drastically reduced, since for the connection of the GPS module not vehicle by vehicle a more or less individual solution must be found. Therefore, in an additional embodiment, the inventive system advantageously comprises a front-end adapted to detect the GPS position of the road vehicle.

It is, of course, of advantage if the system has a switching device capable of detecting the GPS position of the road vehicle, either itself or via a connected GPS module or device having such a GPS module. In that case, the GPS module no longer has to be installed in the front end. It is also advantageous if the switching device can also forward the GPS coordinates. Protection is therefore also claimed for the variant in which the system comprises a switching device which is capable of detecting the global geographical position (GPS position) of the motor vehicle and / or forwarding it to the back-end.

Motor vehicles pollute the environment beyond their fuel consumption, energy use and (LCA) GHG emissions. For example, To be able to determine nitrogen oxide and / or particulate matter emissions, it is usually necessary to know the (stoichiometric) exhaust gas data of a motor vehicle. These can be calculated according to the invention from the fuel consumption. These calculations are nevertheless imprecise, more accurate values are obtained by direct measurement. It is therefore advantageous if the system according to the invention comprises a selection from the following devices or subsystems:

At least one vehicle-internal device (exhaust gas flow meter, exhaust gas mass meter, exhaust gas quantity measuring system, exhaust gas mass measuring system or the like as a vehicle component / subsystem) or a vehicle-external device (exhaust gas flow meter, exhaust gas mass meter, exhaust gas Mass measuring system, exhaust gas mass measuring system or the like as an external automotive component / subsystem), which are adapted to determine the vehicle-specific exhaust gas volumetric flow or exhaust gas mass flow and transmitted to the front end;

• a back-end device (vehicle file) which is suitable for storing exhaust gas data of the motor vehicle and for keeping it retrievable;

• a back-end device (software application, program), which is suitable to calculate from the data transmitted to the back end and / or store and retrievable, which exhaust gas volumes (volumes, masses) the motor vehicle on a certain route, per unit of time, per period, per km, per 100 km, per trip, since commissioning, as a volume fraction of the exhaust gas flow, as mass fraction of the exhaust gas mass flow, mass-based on a passenger-kilometer, volume related to a passenger-kilometer, based on one ton Kilometer or volume related to one tonne kilometer.

Based on the knowledge of the total exhaust gas flow rate or the total exhaust gas mass flow can with commercially available sensors (NO _x sensors, N0 ₂ sensors, according to the principle of conductivity change of easily oxidizable and reducible gases working sensors or the like), the proportion of Nitrogen oxides are determined at the exhaust gas flow. It is therefore advantageous if the system according to the invention comprises a selection from the following devices or subsystems:

At least one vehicle-internal component (NO _x sensor, N0 ₂ sensor, according to the principle of conductivity change of readily oxidizable and reducible gases operating sensor or the like) or a vehicle-external device, which are suitable vehicle specifically to determine or measure the proportion of at least one nitrogen oxide in the exhaust gas volume flow or the proportion of at least one nitrogen oxide in the exhaust gas mass flow and to keep the measured values retrievable;

• a back-end device (vehicle file) which is suitable for storing and retrievable nitrogen oxide data of a motor vehicle;

• a back-end device (software application, program) that is capable of calculating and / or storing from the data transmitted to the back-end and keeping retrievable which quantities of nitrogen oxide (volumes, masses) and / or nitrogen oxide contents (Proportions of the exhaust gas) a motor vehicle on a certain route, per unit time, per period, per km, per 100 km, per trip, since startup, as volume fraction of the exhaust gas flow rate, as a mass fraction of the exhaust gas mass flow, based on a passenger-km, volume related one passenger-kilometer, mass-based to one ton-kilometer or volume-related to one ton-kilometer.

In addition or as an alternative to determining the proportion of nitrogen oxides in the total exhaust gas flow, the system according to the invention can determine whether the ECU control unit responsible for the exhaust gas aftertreatment has switched off the exhaust gas aftertreatment or not. This is done by simply reading and saving the information through the front-end. This means that the OBD2 system reports whether or not the sub-system "Exhaust Aftertreatment" is working, and the front-end stores this data, in addition it can record how high the ambient temperature was with the exhaust aftertreatment switched off (eg to determine whether the exhaust gas aftertreatment was active) The read-out is carried out by the front-end as described above, it is relatively simple since it is ultimately only an additional datum which is read out as usual. with what intensity the sub-system "Exhaust after-treatment" installed in the vehicle works.

Based on the knowledge of the total exhaust gas flow rate or the total exhaust gas mass flow can be determined with commercially available sensors (particulate matter sensor, particulate sensor, soot particle sensor, with special differential signal processing sensors or the like), the fine dust emission. It is therefore advantageous if the system according to the invention comprises a selection from the following devices or subsystems:

At least one vehicle-internal component (fine dust sensor, particle sensor, soot particle sensor, sensors working with special differential signal method or the like) or a vehicle-external device, which are suitable, the vehicle-specific proportion of particulate matter in the exhaust gas flow or to determine or measure the exhaust gas mass flow and to keep the measured values retrievable;

• a back-end device (vehicle file) suitable for storing and retrievable fine dust data of a motor vehicle;

• a back-end device (software application, program) that is capable of calculating and / or saving data from the data transmitted to the back end and to retrieve which fine dust volumes (volumes, masses) and / or particulate matter levels (Proportions of the exhaust gas) a motor vehicle on a certain route, per unit time, per period, per km, per 100 km, per trip, since startup, as volume fraction of the exhaust gas flow rate, as a mass fraction of the exhaust gas mass flow, based on a passenger-km, volume related one passenger-kilometer, mass-based to one ton-kilometer or volume-related to one ton-kilometer. When comparing different types of passenger car with each other, it is advantageous if not only the fuel consumption, energy inputs and emissions per car are known, but the fuel consumption, energy inputs and emissions per passenger or per passenger kilometer. An advantageous development of the system according to the invention can therefore include a device (seat belt, ultrasonic or functionally identical sensor) which is suitable for determining and notifying how many seats in a motor vehicle are occupied on which route section, and / or a backplane. End device (software application, program) which is suitable for calculating vehicle-specific and / or route-specific data from the data transmitted at the back end and / or for storing and retrievable it, such as the fuel consumption, the power consumption that emissions of (LCA) C0 ₂ , particulate matter or nitrogen oxide emissions are absolute, per passenger-kilometer or per passenger per unit of time.

When comparing different commercial vehicle types with each other, it is advantageous if not only the fuel consumption, energy inputs and emissions per commercial vehicle are known, but the fuel consumption, energy inputs and emissions per passenger or per passenger kilometer. An advantageous development of the system according to the invention can therefore consist in that the system comprises a device (pressure sensor, load sensor or the like), which is suitable to determine and report with which payload (net load) or gross load the motor vehicle is loaded on which stretch of road, and / or a back-end device (software application, program) that is capable of calculating vehicle-specific and / or route-specific data from the data transmitted to the back-end and / or storing it and having it retrievable, how high the fuel consumption, the power consumption, the (LCA) C0 ₂ emission, the particulate matter emission or the nitrogen oxide emission is absolute, per ton-kilometer or per tonne and time unit.

In the case of electric vehicles, it is advantageous to know how long vehicle-specific refueling or charging takes on an individual or average basis or how this value develops over time. An embodiment variant of the system according to the invention therefore comprises a device (electronic clock or the like) which is suitable for detecting the time of commencement of refueling of the motor vehicle and the time of termination of the refueling of the motor vehicle or refueling duration (electronic stopwatch or the like) and retrievable to keep.

In order to be able to calculate the fuel consumption, the energy input and the emissions, very specific procedures and calculation methods are required. Only certain components of the system according to the invention make it possible to collect these data. The applicant therefore claims, in particular, protection for the system according to the invention in which a technical value is calculated or determined according to one of the following methods or calculation methods, preferably in the back-end:

2. Identification of the fuel sub-type fueled by petrol vehicles (Super E5 versus Super E10 and other Super Εχγ petrol): by using a device (knock sensor) capable of detecting the anti-knock or octane rating (octane) of a fuel, and from this knock resistance, the proportion of (bio-) ethanol in petrol is determined and Consequently, a distinction can be made between Super E5, Super E10 and other petrol (Super E _xy ).

Identification of the fuel sub-type fueled by diesel vehicles (diesel B7, diesel BIO and other diesel Βχγ fuels): by using a vehicle-internal device suitable for determining the FAME content of a diesel fuel or by comparing the refueling data (GPS Position, main fuel type) from the vehicle file with the data of the refueling file, which relate to the petrol station-specific dispensed fuel sub-types, wherein the identification of the refueling station takes place according to procedure 5;

Identification of the refueled main fuel type in bivalent and dual-fuel vehicles: by retrieving those vehicle-specific stored data and values from the vehicle file related to the propulsion technology (eg diesel / plug-in hybrid, gasoline / plug-in hybrid, Petrol / CNG drive, retrofitted bivalent gasoline / CNG drive, diesel / CNG drive, retrofitted diesel / CNG drive, diesel / LNG drive, retrofitted diesel / LNG drive, CNG / Plugln hybrid, electric drive with range Extender, etc.) and / or by retrieving the refueling data reported to the back end, wherein the fuel-specific tank whose level has increased defines the refueled main fuel type;

Identification of the refueling station (gas station, charging station, other battery charging point) at which a motor vehicle is refueled or charged: by comparison of the global geographical data (GPS coordinates) received from a facility (GPS facility) during refueling reported and ultimately stored in the vehicle file with the global geographical data (GPS coordinates) of the gas stations stored in the gas station file; Identification of the fuel subspecies with which a motor vehicle is refueled or charged: by retrieving the refueling station-specific fuel main and fuel sub-type (or sub-type) from the refueling station file, the refueling station or charging station, at which the motor vehicle has been refueled or previously charged, is previously identified according to procedure 5 (identification of refueling station);

Determination of the route-specific fuel consumption (per km, per 100 km): by dividing the fuel / electricity consumption determined in accordance with procedure 8 by the route determined according to procedure 9; Determining the range (eg km per gallon): by dividing the route determined in accordance with Procedure 9 by the fuel / electricity consumption determined in accordance with Procedure 8;

Determining the route-specific occupancy rate: Division of the sum of all seat-specific routes determined according to procedure 12 by the route determined according to procedure 9, preferably based on the distance covered between two refuelings.

Determining the route-specific fuel consumption per passenger kilometer: Division of the fuel / power consumption determined in accordance with Procedure 10 by the occupancy rate determined in accordance with Procedure 13;

Determination of route-specific (LCA-CCVEmission (per km): Conversion of the route-specific fuel consumption of a motor vehicle determined according to procedure 10 by means of the force determined according to procedure 18 and stored in the fuel file. substance-specific calorific values in a route-specific energy consumption (calorific value consumption) and multiplication of the result with the fuel / electricity-specific (LCA) CO ₂ emission determined according to procedure 19 and likewise stored in the fuel file; Determining the (LCA JCC emissions per passenger kilometers: Division of the calculated pursuant to procedure 20 routes specific ((in GC0 ₂ / km measured) LCA) C0 ₂ emission by the determined according to procedure 13 occupation rate or conversion of according to Procedure 14 determined route-specific fuel consumption per passenger-kilometer by means of the determined according to procedure 17 and stored in the fuel file fuel-specific calorific values in a route-specific energy consumption per passenger kilometer (calorific value consumption) and multiplying the result with the according to the procedure 19 and also stored in the fuel file, fuel-specific (LCA) CO ₂ emissions;

Determination of the route-specific energy consumption per passenger kilometer: conversion of the route-specific fuel consumption determined per procedure 14 per passenger kilometer by means of the fuel-specific calorific values determined according to procedure 17 and stored in the fuel file;

Determination of (LCA-CC emission per tonne-kilometer): Division of the LCA-C0 ₂ emissions of a commercial vehicle measured in accordance with Procedure 20 (measured in gC0 ₂ / km) by the degree of loading determined in Procedure 16 or by conversion of the in accordance with the procedure, route-specific fuel consumption per ton-kilometer using the fuel-specific calorific values determined in accordance with procedure 18 and stored in the fuel file in a route-specific energy consumption per ton-kilometer (calorific value consumption) and multiplying the result by the Procedure 19 determined fuel-specific (LCA) CO ₂ emission also stored in the fuel file;

Determination of the nitrogen oxide mass fraction in the total exhaust gas mass flow: Continuous measurement of the (volatile) nitrogen oxide mass fraction in the total exhaust gas mass flow or continuous measurement of the (volatile) nitrogen oxide volume fraction in the total exhaust gas volumetric flow and multiplication of the both volumes with the respective densities with special consideration of the exhaust gas temperature;

28. Determination of the route-specific nitrogen oxide emission mass: multiplication of the route-specific total exhaust gas mass determined according to procedure 26 with the average nitrogen oxide mass fraction determined in accordance with procedure 27;

29. Determination of the route-specific nitrogen oxide emission mass per passenger kilometer: division of the route-specific nitrogen oxide emission mass determined according to procedure 28 by the route-specific occupancy rate determined according to procedure 13;

30. Determination of the nitrogen oxide emission mass per tonne-kilometer: division of the route-specific nitrogen oxide emission mass determined according to procedure 28 by the route-specific loading level determined according to procedure 16;

31. Determination of Particulate Matter Mass in Exhaust Gas: continuous measurement of particulate volumetric particulate matter in exhaust gas and averaging or incorporation of appropriate default values, typical values or averages from guidelines, laws, ordinances and other government publications into the fuel file;

34. Determination of the particulate matter emission mass per tonne-kilometer: division of the route-specific particulate matter emission mass determined in accordance with procedure 32 by the route-specific loading level determined in accordance with procedure 15;

The inventive system and its developments disclosed herein relate to the LCA-C0 ₂ equivalents in terms of GHG emission. However, it is also possible and possibly advantageous to use the system to determine only the stoichiometric CO ₂ emission values. For this purpose, instead of the fuel-specific LCA-GHG emission values, only the stoichiometric GHG emission values must be entered in the fuel database. The calculation of the values then takes place as in the calculation of the LCA-THG emission values (see above). Therefore, protection is claimed for a variant embodiment in which the system according to the invention determines stoichiometric GHG emission values instead of LCA-GHG emission values.

For public authorities and research institutes in particular, knowledge of aggregated or average fuel consumption, energy input and emission values is more meaningful than knowledge of vehicle-specific values. It goes without saying that all variants of the system according to the invention are to be protected, which generate aggregated values in this regard. These aggregated values include all forms of data aggregation conceivable for a person skilled in the art, in particular data aggregation according to a) motor vehicle type, b) motor vehicle model, c) engine type, d) engine model, e) manufacturer, f) motor vehicle class (eg Upper class, middle class, etc.), g) other motor vehicle segment, h) customer segment, i) district, j) city, k) state, I) Drive type / technology (diesel, gasoline, CNG, LPG, electric, hydrogen etc.), m) main fuel type (including electricity), n) fuel and electricity subspecies, o) period, p) period (eg minute, hour, day, Week, month, quarter, year or a fraction of these periods), q) distance, r) mileage, s) ton-kilometers, t) passenger-kilometers, u) other technical characteristics and criteria.

It is advantageous to determine the difference between the official manufacturer data determined on the occasion of the type approval and the values for fuel consumption, energy consumption and emissions in everyday use in motor vehicles. In one embodiment variant, the system according to the invention therefore comprises a back-end device (software application, program) which is suitable for determining the difference between manufacturer information and values arising in everyday operation with regard to a selection from the criteria fuel consumption (LCA) C0 ₂ . Emission, nitrogen oxide emission, nitrous oxide emissions, particulate matter emission, benzene emissions and the like to calculate and / or store and retrievable.

The results determined by the system according to the invention can be transmitted to a large number of user groups and users. Therefore, a system is to be protected, which includes a device (software application, program, API interface, printer or the like), which is suitable, the investigation results via communication network (Internet, mobile, cable network) or mail letter to at least one of the following (A) a driver of a specific vehicle, (b) a keeper of a specific vehicle, (c) a tax authority, (d) a municipal authority, (e) a transport authority, such as the Federal Motor Transport Authority, f) an environmental authority, g) a vehicle manufacturer, h) a vehicle tuner, i) a vehicle dealer, j) an operator of an internet community, k) a leasing company, I) an insurance company, m) a fuel manufacturer, n) a power generator, o) a tire manufacturer, p) a research institute, q) an environmental institute, r) a GO, s) a company, t) an NGO, u ) another interested body.

The transmission of the results determined by the system according to the invention from the back-end to the user can take place by printout and mailing, via mobile network, via e-mail or via the Internet. Preferably, the at least one user receives an access authorization to the website (Internet presence) of the system operator, which allows him to view and review of there stored investigation results.

Further features, advantages and details of the invention will become apparent from the following drawings.

Brief description of the drawings

The figures show details and embodiments of the invention and that

Fig. 1 is a schematic representation of a very simple embodiment of the system and method according to the invention, in which a vehicle is equipped with sensors, an OBD2 system and a front-end with GPS module, and in which the front-end for data transmission to the Back end is subtracted from the OBD2 socket of the vehicle and plugged into a socket which is connected to an electronic device which is the back-end or which is adapted to the data from the front-end via a communication network to the Transfer backend;

Fig. 2 is a schematic representation of a second embodiment of the system and method according to the invention, in which a vehicle is equipped with sensors, an OBD2 system and a front end with GPS module and a WiFi / WLAN interface, and in which the communication the front-end directly to the back-end wireless via WiFi / WLAN Front-end interface, external Internet access, the Internet, and a back-end Web server;

3 shows a schematic representation of a further embodiment variant of the system and method according to the invention, in which a vehicle is equipped with sensors, an OBD2 system and a front end with GPS module and a mobile radio interface including a mobile communication card (SIM card), and wherein the front-end communication directly to the back-end is wireless via the front-end mobile interface, access to a cellular network, the cellular network, and a back-end gateway;

4 shows a schematic representation of a fourth embodiment variant of the system and method according to the invention, in which a vehicle is equipped with sensors, an OBD2 system, a front end with GPS module and a Bluetooth interface and a Bluetooth-enabled smartphone, and in which the communication of the front-end indirectly with the back-end wirelessly via Bluetooth interface of the front-end, Bluetooth interface of the smartphone, the smartphone, the WiFi / WLAN module of the smartphone, Internet access, the Internet and a web server of the backend takes place;

Fig. 5 is a schematic representation of a fifth embodiment of the system and method according to the invention, in which a vehicle is equipped with sensors, an OBD2 system, a front end with GPS module and a Bluetooth interface and a Bluetooth-enabled smartphone, and where the front-end communication is indirectly connected to the back-end wirelessly via the front-end Bluetooth interface, the smartphone's Bluetooth interface, the smartphone, the mobile phone's cellular module, access to the mobile network, a mobile phone Network and the gateway of the backend;

Fig. 6 is a schematic representation of a sixth embodiment of the system and method according to the invention, in which a vehicle is equipped with sensors, an OBD2 system, a front end with GPS module and WiFi / WLAN interface and WiFi / WLAN-enabled smartphone , and in which the communication of the front-end indirectly with the back-end wirelessly via WiFi / WLAN interface of the front-end, WiFi / WLAN interface of the smartphone, the smartphone, the mobile phone module of the smartphone, access to mobile Network, the mobile network and the back-end gateway;

Fig. 7 is a schematic representation of a seventh embodiment of the system and method according to the invention, in which a vehicle is equipped with sensors, an OBD2 system, a front-end with GPS module and WiFi / WLAN interface and WiFi / WLAN-enabled smartphone and in which the front-end communication communicates indirectly with the back-end wirelessly via the front-end WiFi / WLAN interface, WiFi / WiFi interface of the smartphone, the smartphone, the WiFi / WLAN module of the smartphone, an Internet - Access, the Internet and a web server of the back-end takes place;

8 shows a schematic illustration of an eighth embodiment variant of the system and method according to the invention, in which the GPS position data are not determined and provided by the front end, but by a subsystem of the vehicle;

9 shows a schematic illustration of a ninth embodiment variant of the system and method according to the invention, in which the GPS position data are not determined and provided by the front end, but by the smartphone; 10 shows a schematic representation of a tenth embodiment variant of the system and method according to the invention, in which the GPS position data are not determined and provided by the front end, but by an external third device;

Figure 11 is a schematic representation of the connection of a (new) front-end to the OBD2 socket of a vehicle.

12 is a schematic representation of an optional sequence of the startup of a (new) front-end and its normal operation in the system according to the invention;

Fig. 13 shows a first embodiment of the front-end communicating with a cellular network by means of a wireless modem;

Fig. 14 shows a second embodiment option of the front-end communicating via a Bluetooth interface with a switch which forwards the transmitted data;

Fig. 15 shows a third embodiment of the front-end that communicates with the Internet via a WiFi / WLAN interface, or with a switch that relays transmitted data;

16 illustrates a fourth, simplified front-end execution option communicating via OBD2 parent connector and external OBD2 parent connector with an external device that relays the read data;

Fig. 17 is a schematic illustration of a first embodiment of the installation of a mobile terminal equipped with a cellular modem and a general interface front-end to the OBD2 socket of a passenger car, which is connected to a navigation device;

Fig. 18 is a schematic illustration of a second embodiment of the installation of a front end equipped with a GPS module and a cellular modem at the OBD2 socket of a passenger car;

Figure 19 is a schematic representation of a third embodiment of the installation of a front end equipped with a GPS module and a Bluetooth interface on the OBD2 socket of a passenger car which is wirelessly connected to a smartphone without a GPS function;

20 shows a schematic representation of a fourth embodiment of the installation of a front-end equipped with a Bluetooth interface without a GPS module on the OBD2 socket of a passenger car, which is wirelessly connected to a smartphone provided with a GPS function;

Fig. 21 is a schematic illustration of a fifth embodiment of the installation of a front-end equipped with a WiFi / WLAN interface and a GPS module on the OBD2 socket of a passenger car;

Fig. 22 is a schematic illustration of a sixth embodiment of the installation of a front-end, equipped with a WiFi / WLAN interface, a Bluetooth interface, a mobile radio modem and a GPS module, on the OBD2 socket of a passenger car;

FIG. 23 shows a schematic representation of an embodiment variant of the process of obtaining a refueling data record; FIG. Fig. 24 is an illustration of the raw refueling records of a vehicle;

Fig. 25 is another illustration of the raw data records of a vehicle as transmitted from the front end to the back end;

FIG. 26 shows a simplified algorithm for calculating fuel consumption, energy use and (LCA) GHG emissions; FIG.

, 27 Embodiments of a report of the actual fuel consumption resulting from the everyday use of a vehicle, the corresponding energy input and the corresponding (LCA) GHG emissions.

Detailed description of the drawings

For a better understanding of the present invention, reference will be made below to the embodiments illustrated in the drawings. These are described using specific terminology. The terminology is consistent, that is, the respective designations apply to all figures. It should be understood that the scope of the invention should not be limited by the term of the embodiments illustrated in the drawings. Rather, the embodiments and modifications of the embodiments should also fall under the claimed protection. In addition, it will be obvious to those of ordinary skill in the art having appreciation of the invention that certain changes, additions and modifications will be apparent. Obvious modifications of the method and variants thereof disclosed herein, as well as variations, additions and modifications of the disclosed system and its embodiments, and other obvious applications of the invention will be considered to be common present or future knowledge of a person skilled in the art and are also to be protected.

The features disclosed in the drawings and the claims, advantages and details of the invention may be essential both individually and in any combination with each other for the development of the invention. The basic idea of the invention is not limited to the exact shapes or the details of the embodiments shown below. It is also not limited to an article that would be limited in comparison to the objects described in the claims.

FIG. 1 shows a schematic representation of a simple embodiment variant 10 of a system and method for determining the actual fuel consumption, energy inputs and greenhouse gas emissions during everyday operation of a vehicle, in which a vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3 , an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6 and a front-end 7. The front-end 7 includes in addition to the usual components (CPU / microprocessor, memory module (s), gateway (signal conditioner ), see FIGURES 9 and 10 and prior art) an OBD2 father plug 9, a GPS module 11 with GPS antenna, a clock 12 and an internal power supply 13 with power management subsystem. The GPS module 11 receives the satellite signals of any GPS system 33 (American NAVSTAR GPS, European GALILEO GPS, Russian GLONASS GPS, Chinese BEIDOU GPS) and translates them into GPS coordinates (latitude, longitude, latitude) , Altitude above sea level). The front end internal power supply 13 with power management subsystem, in the event of disconnection of the front end 7 from the OBD2 socket 6 of the vehicle 1, ensures that data stored in the front end 7 is not due to an interruption of the power supply , which is usually done via the OBD2 interface 6 of the vehicle 1, lost. It is also possible to prevent the loss of data by means of a front-end internal storage on a medium or module (not shown) whose storage capacity is independent of a constant power supply of the front-end, such as e.g. Flash SSD is the case.

The front end 7, which is connected via a plug connection 6/9 to the OBD2 system 5 of the vehicle 1, picks up sensor data from the OBD2 system 5 of the vehicle 1, preferably at the beginning and at the end of a refueling. A refueling operation is present when the revolution sensor 3 indicates no revolution and the tank level sensor 2 indicates an increasing level. The front-end 7 detects the data of the tank level sensor 2, the odometer 4, the GPS module 11 and the clock 12 at the start of the refueling operation. Also, the front-end 7 detects this data upon completion of the refueling operation. The refueling process is finished when the turnaround tion sensor 3 after the stoppage of the vehicle 1 and the rise of the tank level detected again a movement of the vehicle 1 and / or if the tank level sensor 2 indicates no further increase in the level.

The data acquired by the front-end 7 is stored in the front-end 7, preferably in the memory module 53 (not shown) and more preferably in the data memory 55 (not shown) until the front-end 7 for data transmission to the back-end 22 is pulled from the OBD2 socket 6 of the vehicle 1 a. The front-end 7 is then plugged with its OBD2 connector 9 on a socket 38 which is suitable, the vehicle-specific data stored in the front-end 7 or a version thereof from the front-end 7 to a device 39 (not shown). The device 39 (eg to a PC connected to the Internet 19, vehicle diagnostic system, laptop, tablet, server, smartphone or the like) is capable of reading this data or a version thereof and forwarding it to the back-end 22 optionally also via communication networks other than the Internet 19 (eg a mobile network 21 (not shown), a telephone landline, a data network, an intranet or the like). That is, the device 39 (not shown) has software capable of communicating with the front-end 7 and reading out data from the front-end 7. The vehicle-specific data (or a version thereof) is read out of the front-end 7 after coupling the front-end 7 to the socket 38 (not shown) and transmitted to the device 39 (not shown). From there, the vehicle-specific data (or a version thereof) is forwarded to the back-end 22. This routing may be to write the data to a volume and send that volume to the back-end 22. Preferably, however, the data is forwarded by the device 39 (not shown) via a communications network, particularly preferably via the Internet 19 to the back-end 22.

The back-end 22 comprises a host system 23. The host system 23 in turn consists of a host server 24, a gateway 25, a web server 26, at least one with CPU / microprocessor 27, at least one random access memory 28 and at least a program memory 29 and the three databases / files vehicle database / file 30, fuel database / file 31 and gas station database / file 32. The host system 23 processes the received data or a version thereof by means of a special Algorithm (see the description of the FIGU R 25) so that the desired results are achieved.

The comparison between the contents of the vehicle file / database 30 and the contents of the gas station file / database 32 preferably takes place on the basis of the GPS coordinates. The comparison between the contents of the gas station file / database 32 and the contents of the fuel file / database 31 is preferably based on the main fuel type 215, particularly preferably based on the fuel subtype and in particular on the basis of time. The alignment between the contents of the fuel file / database 31 and the contents of the vehicle file / database 30 is preferably made on the basis of the main fuel type 215, which is reconciled between the contents of the vehicle file / database 30 and the contents the gas station file / database 32 has been determined. Preferably, the alignment between the contents of the fuel file / database 31 and the contents of the vehicle file / database 30 is made on the basis of the fuel subtype, which is matched between the contents of the vehicle file / database 30 and the contents the gas station file / database 32 has been determined.

Alternatively, omitting the petrol station file / database 32, only a data reconciliation between the vehicle file / database 30 and the fuel file / database 31 can take place. In this case, in the fuel file / database 31, only the specifics of the main fuel types 215 or only the specifics of the common fuels are stored, because it is assumed that a vehicle 1 fuel only a main fuel type 215, for example, a gasoline car only the fuel super E5, a diesel car only the fuel diesel B7, an LPG car only one type of LPG, one natural gas car, only one natural gas type, one electric car, one type of electricity, and one fuel cell car of only one type of hydrogen. In this case, no GPS coordinates are required from the beginning, ie, the front-end does not need to capture GPS data and it does not require a GPS module 11 either.

In the back-end 22, the primary data reported by the front-end 7 or a version thereof is written and stored in the vehicle file / database 30 with or without prior caching. Based on the adjustments described above, the host server 24 determines vehicle-specific primary data from the vehicle-specific primary data, such as vehicle-specific secondary data. the distance covered by the vehicle between two refuelings, the distance traveled by the vehicle 1 between a time period, its route-specific fuel consumption, its period-specific fuel consumption, its route-specific (LCA) GHG emissions and its period-specific (LCA) -) GHG emissions. It will be appreciated that the host server 24 may also determine other vehicle-specific secondary data that will be apparent to one of ordinary skill in the art after having understood the invention. It also goes without saying that the primary data and / or the determined secondary data can be aggregated over several vehicles 1.

The host server 24 writes the vehicle-specific secondary data and / or aggregated secondary data back to the vehicle file / database 30 and / or makes it or a version thereof available to the web server 26. The vehicle-specific secondary data and / or aggregated secondary data may also be output to a printer (not shown) for the purpose of creating a hard copy. The web server 26 creates from the received data a selection of report forms reports, statements, graphics, summaries and the like. These reports are sent to the owners and / or drivers of the vehicles 1, preferably by mail, particularly preferably via the Internet via e-mail. However, it is also possible to inspect authorized users (driver / vehicle owner / other authorized person) in the various report forms, preferably via a user PC or the like (any suitable communication terminal such as smartphone, tablet, laptop, intranet server, etc.) and via the Internet 19 at the web server 26.

Preferably, the user can view vehicle-specific monthly reports 34 showing how many kilometers a vehicle 1 traveled in a month, which types of fuel were fueled, what fuel has consumed the vehicle 1 in this month, which fuel consumption per kilometer which energy input corresponds to the monthly fuel consumption, which energy use per kilometer this corresponds to, which (LCA) GHG emissions caused the vehicle 1 in the month and which (LCA) GHG emission this corresponds to per kilometer. It goes without saying that the web server 26 can provide corresponding vehicle-specific reports also for other time periods (day, week, quarter, half-year, year, vehicle use time, etc.).

FIG. 2 shows a schematic representation of a second embodiment variant 40 of a system and method for determining the actual fuel consumption, energy inputs and greenhouse gas emissions during everyday operation of a vehicle, in which a vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3 , an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6 and a front end 7. The front end 7 includes an OBD2 father plug 9, a GPS module 11, a clock 12 and a WiFi / WLAN interface 14. The GPS module 11 receives the satellite signals of any GPS system 33 (American NAVSTA -G PS, European GALI LEO-GPS, Russian GLONASS GPS, Chinese AT DOU-GPS) and translate them into GPS coordinates (longitude, latitude, altitude above sea level).

The front end 7, which is connected via a plug connection 6/9 to the OBD2 system 5 of the vehicle 1, picks up sensor data from the OBD2 system 5 of the vehicle 1, preferably at the beginning and at the end of a refueling. A fueling operation is when the revolution sensor 3 indicates no revolution and the tank level sensor 2 indicates an increasing level. The front-end 7 detects the data of the tank level sensor 2, the odometer 4, the GPS module 11 and the clock 12 at the start of the refueling operation. Also, the front-end 7 detects this data upon completion of the refueling operation. The refueling process is ended when the revolution sensor 3 again detects a movement of the vehicle 1 after the standstill of the vehicle 1 and the rise of the tank level and / or if the tank level sensor 2 indicates no further increase in the level.

Both the front-end 7 and the smartphone 8 have software apps that enable them to communicate with each other, either via a Bluetooth or WiFi / Wi-Fi connection. This app can refer / download the smartphone 8 from central locations (Google Play, App Store) and continue to transmit to the front-end 7, if this was not already equipped with the required communication software variants at delivery by the operator of the system according to the invention. In this way, changes in the work instructions (new data collection scheme, new Datenü transmission path from the front-end 7 to the back-end 22) in the smartphone 8 and in the front-end 7 are made.

The data acquired by the front-end 7 is stored in the front-end 7, preferably in the memory module 53 (not shown) and more preferably in the data memory 55 (not shown) until the front-end 7 via its WiFi / WLAN interface 14 and a suitable external WiFi / WLAN Internet access 18 can establish a WiFi / WLAN connection to the Internet 19. Once this is the case, the front-end 7 transmits directly or wirelessly the cached data or a version thereof via its WiFi / WLAN interface 14 and the external Internet access 18, which is preferably WiFi / WLAN access the Internet 19 and a web server 26 of the back end 22 to the host server 24 of the back end 22.

The back end 22 comprises, as in FIG. 1, a host system 23. The host system 23, in turn, consists of a host server 24, a gateway 25, a web server 26, at least one with a CPU / microprocessor 27, at least one Work memory 28 and at least one program memory 29 and the three databases / files vehicle database / file 30, fuel database / file 31 and gas station database / file 32. The host system 23 processes the received data or a version of which by means of a special algorithm (see description of FIGU R 25) so that the desired results are achieved.

The comparison between the contents of the vehicle file / database 30 and the contents of the gas station file / database 32 takes place, as in FIG. R 1, preferably on the basis of the GPS coordinates. The comparison between the contents of the gas station file / database 32 and the contents of the fuel file / database 31 is carried out as in FIGURE 1 preferably based on the main fuel 215, more preferably based on the fuel subspecies and in particular on the Base of time. The comparison between the contents of the fuel file / database 31 and the contents of the vehicle file / database 30 is made as in FIGURE 1, preferably on the basis of the main fuel type 215, which when reconciled between the contents of the vehicle file / database 30 and the contents of the gas station file / database 32 has been determined. In front- Preferably, the comparison between the contents of the fuel file / database 31 and the contents of the vehicle file / database 30 is made on the basis of the fuel subtype, which, when reconciled between the contents of the vehicle file / database 30 and the contents of the Petrol station file / database 32 was determined.

Alternatively, omitting the gas station file / database 32, only a data synchronization between the vehicle file / database 30 and the fuel file / database 31 can take place. In this case, only the specifics of the main fuel types 215 or only the specifics of the common fuels have to be stored in the fuel file / database 31, because it is assumed that a vehicle 1 only refuels a main fuel type 215, e.g. a gasoline car only the fuel super E5, a diesel car only the fuel diesel B7, an LPG car just an LPG grade, a natural gas car just a natural gas type, an electric car just a power type and a fuel cell car just a hydrogen Art. In this case, no GPS coordinates are required from the beginning, that is, the front end does not need to acquire GPS data, nor does it require a GPS module 11.

In the back-end 22, the primary data reported by the front-end 7 or a version thereof are written and stored in the vehicle file / database 30 as in FIG. 1 with or without prior buffering. Based on the adjustments described above, the host server 24 determines vehicle-specific primary data from the vehicle-specific primary data, such as vehicle-specific secondary data. the distance covered by the vehicle between two refuelings, the distance traveled by the vehicle 1 between a time period, its route-specific fuel consumption, its period-specific fuel consumption, its route-specific (LCA) GHG emissions and its period-specific (LCA) -) GHG emissions. It will be appreciated that the host server 24 may also determine other vehicle-specific secondary data that will be apparent to one of ordinary skill in the art after having understood the invention. It also goes without saying that the primary data and / or the determined secondary data can be aggregated over several vehicles 1.

The host server 24 writes back the vehicle-specific secondary data and / or aggregated secondary data as in FIG. 1 to the vehicle file / database 30 and / or makes it or a version thereof available to the web server 26. The vehicle-specific secondary data and / or aggregated secondary data may also be output to a printer (not shown) for the purpose of creating a hard copy. The web server 26 creates from the received data a selection of report forms reports, statements, graphics, summaries and the like. These reports are sent to the owners and / or drivers of the vehicles 1, preferably by mail, particularly preferably via the Internet via e-mail. However, it is also possible to inspect authorized users (driver / vehicle owner / other authorized person) in the various report forms, preferably via a user PC or the like (any suitable communication terminal such as smartphone, tablet, laptop, intranet server, etc.) and via the Internet 19 at the web server 26.

Preferably, as in FIG. 1, the user can view vehicle-specific monthly reports 34, which show how many kilometers a vehicle 1 traveled in a month, which types of fuel were fueled, what fuel quantity the vehicle 1 consumed in that month, which fuel consumption per kilometer corresponds to which energy use corresponds to the monthly fuel consumption, which energy use per kilometer this corresponds to, which (LCA) GHG emissions caused the vehicle 1 in the month and which (LCA) GHG emission this corresponds to per kilometer. It goes without saying that the web server 26 corresponding Can also provide vehicle-specific reports for other time periods (day, week, quarter, half year, year, vehicle usage time, etc.).

FIG. 3 schematically illustrates a third embodiment variant 60 of a system and method for determining the fuel consumption, energy inputs and greenhouse gas emissions that actually occur during everyday operation of a vehicle, in which the communication of the front-end 7 with the back-end 22 is wireless via mobile radio. Interface 15 of the front-end 7 and a mobile phone mast 20 of the mobile network 21 takes place. As described in FIG. 2, the vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3, an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6 and a front end 7. The front-end 7 comprises an OBD2 father connector 9, a GPS module 11, a clock 12, but no WiFi / WLAN interface, but a mobile radio interface 15 including a mobile communication card (SIM card) 16. The communication of the Front-Ends 7 with the back-end 22 as shown in FIG 2 also wirelessly, but not via WiFi / WLAN interface of the front-end 7 but via the mobile interface 15 of the front-end 7 and a suitable access to mobile Network 21, the eg a mobile mast 20 may be a gateway 25 of the back-end 22 to the host server 24 of the back-end 22.

The back-end 22 is connected via a gateway 25 to the mobile network 21. Otherwise, the system according to the invention in this embodiment is constructed as described in FIGURE 2, it works otherwise as well. To avoid repetition, reference is made to the detailed description of FIG.

FIG. 4 shows a schematic representation of a fourth embodiment 70 of the system and method according to the invention for determining the actual fuel consumption, energy inputs and greenhouse gas emissions during everyday operation of a vehicle, in which the communication of the front-end 7 with the back-end 22 is wireless and indirect via Bluetooth interface 17 of the front-end 7, a Bluetooth-enabled smartphone 8, a suitable access 18 to the Internet and the Internet 19 takes place. As described in FIG. 2, the vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3, an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6 and a front end 7. The front-end 7 comprises an OBD2 father plug 9, a GPS module 11, a clock 12, but neither a WiFi / WLAN nor a mobile radio interface, but a Bluetooth interface 17. The front-end communication 7 with the back-end 22 takes place wirelessly and indirectly, initially via Bluetooth interface 17 of the front-end 7 to a Bluetooth-enabled smartphone 8, in the smartphone from the Bluetooth chip with or without caching to the WiFi / WLAN module 14 ^' , via which a smartphone 8 usually has, and from there via an Internet access 18, the Internet 19 and a web server 26 of the back-end 22 to the host system 23 of the back-end 22.

Both the front-end 7 and the smartphone 8 have software apps that enable them to communicate with each other via either a Bluetooth or WiFi / Wi-Fi connection. This app can refer / download the smartphone 8 from central locations (Google Play, App Store) and continue to transmit to the front-end 7, if this was not already equipped with the required communication software variants at delivery by the operator of the system according to the invention. In this way, changes in the work instructions (new data collection scheme, new data transmission path from the front-end 7 to the back-end 22) in the smartphone 8 and in the front-end 7 are made.

The data acquired by front-end 7 are stored in the front-end 7, preferably in the memory module 53 (not shown) and particularly preferably in the data memory 55 (not shown) until the front-end 7 via its Bluetooth interface 17 with the Bluetooth-enabled smartphone 8 can connect. Once this is the case, the front-end 7 transmits the cached data or a version thereof via the established Bluetooth connection to the smartphone 8. The smartphone 8 transmits the data received from the front-end 7 or a version thereof with or without caching via its WiFi / WLAN module 14 ^' to a suitable Internet access 18, thus the Internet 19 and from there to the back-end 22. Otherwise, the inventive system is constructed in this embodiment as described in FIGURE 2, it works otherwise even so. To avoid repetition, reference is made to the detailed description of FIG.

FIG. 5 shows a schematic representation of a fifth variant 80 of the system and method according to the invention for determining the actual fuel consumption, energy inputs and greenhouse gas emissions that arise during everyday operation of a vehicle. As described in FIG. 2, the vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3, an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6 and a front end 7. The front-end 7 comprises an OBD2 father plug 9, a GPS module 11, a clock 12 and a Bluetooth interface 17. The communication of the front-end 7 with the back-end 22 is wireless and indirectly via a switching device 61, which is a smartphone 8 in this embodiment and that initially via Bluetooth interface 17 of the front-end 7 and the Bluetooth interface (chip) of the smartphone 8, the smartphone 8 itself, the mobile module of the smartphone 8, an access to a mobile network 20, the mobile network 21, the gateway 25 of the back-end 22 to the host server 24 of the back-end 22.

The data collected by the front-end 7 are stored in the front-end 7, preferably in the memory module 53 (not shown) and particularly preferably in the data memory 55 (not shown) until the front-end 7 via its Bluetooth interface 17 with the Bluetooth-enabled smartphone 8 can connect. Once this is the case, the front-end 7 transmits the cached data or a version thereof via the established Bluetooth connection to the smartphone 8. The smartphone 8 transmits the data received from the front-end 7 or a version thereof to its mobile phone. Module and from there via a suitable access to the mobile network 20 and the mobile network 21 itself to the back-end 22. Otherwise, the system according to the invention is constructed in this embodiment as described in FIGURE 2, it works otherwise as well. To avoid repetition, reference is made to the detailed description of FIG.

FIG. 6 schematically shows a sixth embodiment 90 of the system and method according to the invention for determining the actual fuel consumption, energy inputs and greenhouse gas emissions which are actually generated during everyday operation of a vehicle. As described in FIG. 2, the vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3, an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6 and a front end 7. The front-end 7 includes an OBD2 father plug 9, a GPS module 11, a clock 12 and a WiFi / WLAN Interface 14. The communication of the front-end 7 with the back-end 22 is wireless and indirectly via a switching device 61, which is a smartphone 8 in this embodiment, namely first via WiFi / WLAN interface 14 of the front-end 7 and WiFi / WLAN interface 14 ^'of the smartphone 8, the smartphone 8 itself, the mobile radio module of the smartphone 8, an access to a mobile radio network 20, the mobile radio network 21, the gateway 25 of the back-end 22 to the host computer. Server 24 of back-end 22.

The data acquired by the front-end 7 is stored in the front-end 7, preferably in the memory module 53 (not shown) and more preferably in the data memory 55 (not shown) until the front-end 7 via its WiFi / WLAN interface 14 and the WiFi / WLAN interface 14 ^'of the smartphone 8 can establish a connection. Once this is the case, the front-end 7 transmits the cached data or a version thereof via the established WiFi / WLAN connection to the smartphone 8. The smartphone 8 transmits the data received from the front-end 7 or a version thereof Cellular module and from there via an access to a mobile network 20 and the mobile network 21 to the back-end 22. Otherwise, the system according to the invention is constructed in this embodiment as described in FIGURE 2, it works otherwise as well. To avoid repetition, reference is made to the detailed description of FIG.

FIG. 7 schematically shows a seventh embodiment variant 100 of the system and method according to the invention for determining the actual fuel consumption, energy inputs and greenhouse gas emissions that arise during everyday operation of a vehicle. As described in FIG. 2, the vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3, an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6 and a front end 7. The front-end 7 comprises an OBD2 father plug 9, a GPS module 11, a clock 12 and a WiFi / WLAN interface 14. The communication of the front-end 7 with the back-end 22 is wireless and indirect via a switching device 61, which is a smartphone 8 in this embodiment, namely first via WiFi / WLAN interface 14 of the front-end 7 and the WiFi / WLAN interface 14 ^'of the smartphone 8 to the smartphone 8 itself and from there with or without caching via the WiFi / WLAN interface 14 ^'of the smartphone 8 and via an Internet access 18, the Internet 19 and the web server 26 of the back-end 22 to the host server 24 of the back-end 22.

Both the front-end 7 and the smartphone 8 have software apps that enable them to communicate with each other via either a Bluetooth or WiFi / Wi-Fi connection. This app can refer / download the smartphone 8 from central locations (Google Play, App Store) and continue to transmit to the front-end 7, if this was not already equipped with the required communication software variants at delivery by the operator of the system according to the invention. In this way, changes in the work instructions (new data collection scheme, new data transmission path from the front-end 7 to the back-end 22) in the smartphone 8 and in the front-end 7 are made. The data acquired by the front-end 7 is stored in the front-end 7, preferably in the memory module 53 (not shown) and more preferably in the data memory 55 (not shown) until the front-end 7 via its WiFi / WLAN interface 14 and the WiFi / WLAN interface 14 ^'of the smartphone 8 can connect to the smartphone 8. Once this is the case, the front-end 7 transmits the cached data or a version thereof via the established WiFi / WLAN connection to the smartphone 8. The smartphone 8 transmits the data received from the front-end 7 or a version thereof with or without caching via its WiFi / WLAN interface 14 ^' to an Internet access 18 and from there via Internet 19 and web server 26 of the back-end 22 to the host server 24 of the back-end 22. Otherwise, the inventive system is in this embodiment is constructed as described in FIGURE 2, it works otherwise as well. To avoid repetition, reference is made to the detailed description of FIG.

FIG. 8 shows a schematic representation of an eighth embodiment variant 110 of the system and method according to the invention for determining the actual fuel consumption, energy inputs and greenhouse gas emissions during everyday operation of a vehicle, in which the GPS position data are not determined and provided by the front-end 7, but instead from a subsystem 35 of the vehicle. This sub-system 35 is suitable for determining GPS coordinates and forwarding them to the OBD2 system 5 of the vehicle. As described in FIG. 2, the vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3, an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6 and a front end 7. The front-end 7 comprises an OBD2 father plug 9, but no GPS module 11, a clock 12 and a selection of WiFi / WLAN interface 14, mobile radio interface 15 with mobile card / SIM card 16 and Bluetooth Interface 17.

Via the WiFi / WLAN interface 14 of the front-end 7, either a direct connection to the back-end 22 via Internet access 18 into the Internet 19 to the web server 26 of the back-end 22 and to the host server 24 of the back-end. 8. Both the front-end 7 and the smartphone 8 have software apps that enable them to communicate with each other, either via Bluetooth or WiFi / Wi-Fi connection. This app can refer / download the smartphone 8 from central points (Google Play, App Store) and continue to transmit to the front-end 7, if this is not already equipped with the required communication software variants when delivered by the operator of the system according to the invention has been. In this way, changes in the work instructions (new data collection scheme, new data transmission path from the front-end 7 to the back-end 22) in the smartphone 8 and in the front-end 7 can be made.

From the smartphone 8, the connection to the back-end 22 can then be established either via the WiFi / WLAN module 14 ^'of the smartphone 8, Internet access 18, Internet 19 and web server 26 of the back-end 22 or via the mobile radio network. Module 15 ^'of the smartphone 8, access to the mobile network 20, the mobile network 21 and a gateway 25 of the back-end 22. This results in three possible communication channels.

Via the mobile radio interface 15 (with mobile card / SIM card 16) of the front-end 7, a direct connection to the back-end 22 is established, namely via access to a mobile network 20, the mobile network 21 and a Gateway 25 of the back-end 22. This represents another possible communication path.

An indirect connection to the back-end 22 is established via the Bluetooth interface 17 of the front-end 7 via a smartphone 8 that is capable of Bluetooth. From the smartphone 8, the Connection to the back-end 22 then either via the WiFi / WLAN module 14 ^'of the smartphone 8, Internet access 18, Internet 19 and web server 26 of the back-end 22 are constructed or via the mobile module 15 ^{' of} the smartphone 8, access to the mobile network 20, the mobile network 21 itself and a gateway 25 of the back-end 22. This results in two further possible communication paths.

The GPS module 11 providing the GPS coordinates in this embodiment is a module of the subsystem 35 of the vehicle 1 which supplies the GPS coordinates to the OBD2 system 5 of the vehicle 1. That is, the front end 7 does not generate the GPS coordinates internally, but obtains them via the connector 6/9 from the OBD2 system 5 of the vehicle 1.

The communication of the front-end 7 with the back-end 22 in this embodiment of FIGURE 8 may optionally be as described above, i. This variant has a total of 6 sub-variants, which are defined by the possible communication paths. Otherwise, the system according to the invention in this embodiment is constructed as described in FIGURE 2, it works otherwise as well. To avoid repetition, reference is made to the detailed description of FIG.

FIG. 9 shows a schematic representation of a ninth embodiment variant 120 of the system and method according to the invention for determining the actual fuel consumption, energy inputs and greenhouse gas emissions during everyday operation of a vehicle, in which the GPS position data are not determined and provided by the front-end 7, but instead from a subsystem 36 of the smartphone 8. This subsystem 36 is capable of detecting GPS coordinates and relaying them to the front-end 7 or the back-end 22. As described in FIG. 8, the vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3, an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6, and a front end 7. The front-end 7 comprises an OBD2 father plug 9, but no GPS module 11, a clock 12 and a selection from WiFi / WLAN interface 14, mobile radio interface 15 with mobile radio card / SIM card 16 and Bluetooth interface 17.

In this embodiment, the GPS module 36 supplying the GPS coordinates is a module or a subsystem 36 of the smartphone 8. It supplies the GPS coordinates via WiFi / WLAN or Bluetooth to the front-end 7, to the smartphone 8 itself or This means that the front-end 7 does not internally generate the GPS coordinates, but receives them via the Bluetooth connection from the smartphone 8 or it sends the beacons to the back end. kung data records without GPS coordinates to the back-end 22 and the merger of refueling data and GPS coordinates takes place only in the back-end 22 after the smartphone 8 has transmitted the GPS coordinates to the back-end 22.

The communication of the front-end 7 with the back-end 22 in this embodiment of FIGURE 9 may optionally be as described above for the embodiment of FIGURE 8, i. This embodiment variant of FIG. 9 also has 6 sub-variants, which are defined by the possible communication paths. Otherwise, the system according to the invention in this embodiment is constructed as described in FIGURE 2, it works otherwise as well. To avoid repetition, reference is made to the detailed description of FIG.

FIG. 10 shows a schematic representation of a tenth embodiment variant 130 of the system and method according to the invention for determining the actual fuel consumption, energy inputs and greenhouse gas emissions during everyday operation of a vehicle, in which the GPS position data are not determined and provided by the front-end 7, but instead from one third, vehicle-external device 37, which may be a navigation system 85 or the like. Vehicle-external means in this context, not originally associated with the vehicle equipment. Typically, this includes a retrofitted navigation system 85, a laptop connected to the front end with GPS module 11, a connected to the front-end clock with GPS module 11, a tablet with GPS module 11 and the like. The device 37 is suitable for determining GPS coordinates and forwarding them to the front-end 7 or the back-end 22. For example, a cable-tethered connection between the front-end 7 and the device 37 is possible, preferably via a general interface for peripheral devices 56 of the front-end 7.

As described in FIG. 2, the vehicle 1 is equipped with a tank level sensor 2, a revolution sensor 3, an odometer 4, an OBD2 bus 5, an OBD2 nut socket 6 and a front end 7. The front-end 7 comprises an OBD2 father plug 9, but no GPS module 11, a clock 12 and a selection of WiFi / WLAN interface 14, mobile radio interface 15 with mobile card / SIM card 16 and Bluetooth Interface 17.

The GPS coordinates providing device 37 in this embodiment is a peripheral device that provides the GPS coordinates to the front end 7 or to the back end 22. That is, the front-end 7 does not internally generate the GPS coordinates, but obtains them via an appropriate connection from the device 37 or it sends the refueling data sets without GPS coordinates directly or indirectly to the back-end 22 and the merge of Refueling data and GPS coordinates only take place in the back-end 22 after the device 37 has transmitted the GPS coordinates to the back-end 22.

The communication of the front-end 7 with the back-end 22 in this embodiment of FIG. 10 may optionally be as described above for the embodiment of FIG. 8, i. This embodiment variant of FIG. 10 also has 6 sub-variants, which are defined by the possible communication paths. Otherwise, the system according to the invention in this embodiment is constructed as described in FIGURE 2, it works otherwise as well. To avoid repetition, reference is made to the detailed description of FIG.

11 shows a schematic representation of the connection procedure 140 of a (new) front end 7 to the OBD2 nut socket 6 of a vehicle 1. This procedure 140 may be required not only for the installation of a new front end 7, but also for the case that the front end 7 has been subtracted from the OBD2 nut socket 6 of the vehicle 1 while the connection to the mobile network 21 or the Internet 19 or data has been lost.

In the embodiments in which the front-end communicates directly with the back-end (see FIGURES 2 and 3), the attachment procedure involves attaching the front-end 7 to the OBD2 socket 6, usually underneath the dashboard of the vehicle 1 is located. After the front-end 7 via the OBD2 socket 6 of the vehicle 1 (again) obtains data from the OBD2 system 5, it takes as the program (possibly firmware) given (re) work.

In the embodiment variants in which the front-end 7 communicates with the back-end 22 via a switching device 61 (see FIGURES 4 to 7), a special software application (software program, app) which improves the switching device 61, to take over the functions provided by the method or system according to the invention from a central location (eg from Google Play, from the Apple Store, website of the system operator or the like) via a suitable communication network (Internet 19, mobile network 21 or the like) to the switching device 61 downloaded. It is also possible to transfer this special app via hardware (eg USB stick, CD or similar) and via a suitable interface / peripheral device to the switching device 61. In the embodiment of FIGURE 11, the switching device 61 is a smartphone 8, but the switching device 61 can also be any other communication terminal that is suitable for the purpose described here or the implementation of these functions.

The special software application (App) that upgrades the switching device 61 or the smartphone 8 to take over the functions provided by the method or system according to the invention can also have already been transmitted to the smartphone 8 by the manufacturer, the smartphone 8 can So already with this special software application (firmware) are supplied by the manufacturer.

After downloading the special app on the smartphone 8, a special sub-routine (work instruction) of the new smartphone app is activated, which guides the user (smartphone owner), such as the registration of his vehicle 1, the front-end 7 and his Smartphones 8 at the operator of the system to determine the actual fuel consumption, energy inputs and greenhouse gas emissions in the everyday operation of a vehicle has to be made. After completion of this registration, which can also be done bypassing the smartphone 8 (eg via the dial-up of a user PC connected to the Internet 19 in the back end 22 of the system operator), the smartphone 8 via Bluetooth or WiFi / WLAN Make contact with the plugged into the OBD2 socket 6 of the vehicle 1 front end (OBD2 adapter) 7, which is thus supplied with power from the vehicle battery. If the front end 7 (or the OBD2 adapter) has not already been equipped by the manufacturer with special adapter software (adapter app), the smartphone 8 transmits the special adapter software via Bluetooth or WiFi / WLAN connection on the front-end 7 (the OBD2 adapter), more specifically in the memory module 53 of the front-end 7, preferably in the program memory 54 of the memory module 53 (for further details, reference is made to the prior art). It is also possible to transfer this software by means of a memory card via the mobile card slot 16 of the front-end 7.

The front-end 7 is thus initialized and ready for operation, i. it is capable of recording operating data of the vehicle 1, in particular odometer readings, possibly traveled distances between two refuelings (charges), information on the types of fuel fueled (types of fuel), tank levels (battery charge states) and / or refueled fuel quantities (charged amounts of electricity), store, provided with a time stamp and directly via the communication network 19/21 to the back-end 22 or indirectly first to the smartphone 8 and then continue to transfer via the communication network 19/21 to the back-end 22. If the front-end 7 is equipped with a GPS module 11 or connected to such a GPS module 11, it is also able to supplement the operating data of the vehicle 1 with GPS coordinates.

FIGURE 12 schematically illustrates in a flow chart 150 how a variant embodiment of the registration of a (new) front end 7 in the system 40, 60, 70, 80, 90, 100, 110, 120, 130 according to the invention expires and how it is more common Operation takes place in this embodiment. First, there is a download 212 of the work instructions for the smartphone 8 and the front-end 7 in the form of software. After download 212, both the front-end 7 and the smartphone 8 have software apps that enable them to communicate with each other via either a Bluetooth or WiFi / Wi-Fi connection. This app can refer the smartphone 8 from central points (Google Play, App Store) and transmitted to the front-end 7, if this was not already equipped at the time of delivery by the operator of the system according to the invention with the required communication software. The apps also include work instructions for the collection of data, the transmission of data packets and the selection of communication channels.

In a second step, the registration 62 of the vehicle 1, the vehicle owner and / or the driver and the front-end 7 takes place at the back end 22, in which the administration of the system according to the invention is located. The registration typically takes place over the Internet 19, e.g. by dialing into the website of the system operator or the back-end 22, which is hosted by the web server 26 of the back-end 22. The dial-in and the registration can be made via a smartphone 8, a tablet, a laptop, a PC or any other suitable communication terminal. Various queries ensure that the back-end 22 receives all the information needed to operate the system. If the query "registration completed?" Shown in block 63 is answered in the affirmative, the user can insert the front end 7 with his predetermined, original data collection scheme as shown at block 64 onto the OBD2 mother socket 6 of his vehicle 1 (FIG. see FIGU R 11) The front-end 7 is supplied from this time via the PI N 16 of the OBD2 socket 6 with power from the vehicle battery and is ready for operation.

For the purpose of mutual verification and approval of the front-end 7 in the system 40, 60, 70, 80, 90, 100, 110, 120, 130 according to the invention, a smartphone 8 is controlled by a special app (eg a "know your footprint"). -App) connects to and contacts the front-end 7. The front-end 7 communicates its device number and software version, after which the front-end 7 displays the If necessary, the smartphone 8 plays or activates another software version on the front-end 7 if the new version already exists on the front-end 7. This verification process is summarized in block 65. Then in the front-end 7 and / or in the smartphone 8, controlled by appropriate software-based work instructions, a check is made as to whether the verification procedure has been completed (see block 66) If this is not the case, the user must go back to the registry 62 to resolve any discrepancies clarify or to eliminate data deficits.

When the verification 65 is completed according to query 66, the front-end 7, as shown in block 67, communicates with the OBD2 system 5 of the vehicle 1 by serializing the various communication protocols (SAE-J1850-VPW, SAE-J1850-VPWM, ISO, ISO 9141-2, KWP, KWP 2000, CAN etc.). If the host computer of OBD2 system 5 of vehicle 1 has not yet responded (see block 68), front end 7 continues its efforts as shown in flow 150. When the host computer has responded, the front-end 7 stores the protocol used in case there is an interruption of contact with the OBD2 system 5 (e.g., at a garage visit of the vehicle). From then on, the front-end 7 reads the data available at the OBD2 socket 6 of the vehicle 1, selects the data to be stored according to the work instruction, assigns the data with a date and time stamp and stores the entire data set, as shown in the Program memory 54 of the front-end 7 stored work instruction (data collection scheme) pretends. This "data monitoring and data storage" step is shown as block 69.

In parallel to the data collection, the front-end 7 processes the work instruction, after which the existence of a data-delivery reason is examined (see block 71). These occasions may consist of reaching a certain date (end of month), reaching a certain time (end of day), an external impulse, completing a refueling operation, establishing a connection with a mobile network, connecting to a peripheral device, and the like. If there is no such occasion, the front end continues its data collection as shown in flow 150. If such an occasion exists, the front-end chooses the communi- kationsweg after a corresponding work instruction, which is stored as software in the program memory 54 of the front-end 7 (shown as block 72).

If the recipient of the data packet to be sent by the front-end 7 is a switch 61 or a smartphone 8 (see block 73), the front-end 7 sends the raw data packet via WiFi / WLAN interface 14 or as shown in block 75 via bluetooth interface 17 to the switching device 61 or to the smartphone 8. If the receiver is not a switching device 61 or a smartphone 8, the front-end 7 transmits the raw data packet as subsumed under block 74 directly via mobile modem 15 , Mobile access 20 and cellular network 21 or via WiFi / WLAN interface 14, Internet access 18, Internet 19 and web server 26 to the host server 24 of the back-end 22.

If the direct transfer of the raw data packet from the front-end 7 to the back-end 22 has been successful (see block 78), which can be checked via various check routines (see prior art), the back-end 22 stores the from at least a data set between (see block 81). If the direct transmission of the data packet from the front-end 7 to the back-end 22 has not been successful, the process is repeated with the step 74 (see flowchart 150).

If the (indirect) transmission of the raw data packet consisting of at least one data record from the front-end 7 to the smartphone 8 was successful (see block 76), which can be checked via various check routines (see prior art), the smartphone sends 8 the raw data packet as shown at block 77 with or without caching via communication network (access to mobile network 20 and mobile network 21 or Internet access 18 and Internet 19) to the back-end 22, otherwise the Abiaufschritt 75 must be repeated , If this data transfer was also successful (see query 79), the back-end 22 will store the transmitted raw data packet (see block 81), otherwise step 77 must be repeated (see flow 140).

In block 82, the back-end 22, or more precisely: a work instruction stored as software in the program memory 29 of the host computer 24 of the host system 23, checks whether there is a reason for the data analysis. If this is not the case, the gateway 25 and the web server 26 of the host system 23 wait for the receipt of the next data packet, the i.d.R. due to the plurality of vehicles 1 is sent from another front-end T. If there is a cause for data analysis (eg, expiration of a period, achievement of a particular time, manual initiation, single query, or the like), back-end 22, as indicated by block 83, uses a special algorithm to parse and / or calculate data accordingly Work instructions that are stored in the form of software in the program memory 29 of the host server 24 or rewritten from case to case. The data sets supplemented by the calculation results puts the back-end 22 into the web server 26 where it is available to the users (see block 84). These users can view the finished data records and possibly also the raw data that concerns them with the corresponding access authorization. It is also possible to prepare various reports, e.g. sent by e-mail or by post to the user and / or other interested parties.

FIG. 13 shows a first embodiment of the front-end 7. It is connected via an OBD2 plug contact 6/9 to the OBD2 bus 5 of the vehicle 1 (not shown). In this embodiment, which is again only one of many possible variants, the components of the front-end 7, which with its OBD2 father plug 9 into the OBD2 nut socket 6 (socket format J1962) of the vehicle 1 ( not shown), schematically illustrated. provides. The 0BD2 book 6 is supplied with data from the host computer 43 of the OBD2 system 5 of the vehicle 1 (not shown). The role of the host computer may be assumed by an Electronic Control Module (ECM) 41 (not shown) and / or a Power Control Module (PCM) 42 (not shown). About manufacturer-specific occupied PINs (see respective PIN assignment of the OBD2 interface), the OBD2 nut socket 6 via the vehicle BUS 5 with data from electronic control units (Electronic Control Units ECU 43, 43 ¹ , 43 ² , 43 ³ ) are supplied. The battery 213 of the vehicle 1 supplies power to the front end 7 via the PIN 16 of the OBD2 plug contact 6/9.

In the embodiment of FIGURE 13, the front end 7 is an OBD2 adapter. In addition to the usual components, modules and components, which has such an OBD2 adapter (see prior art), it includes a housing 44, in which an OBD2 father plug 9 is embedded. It also has a communication interface (gateway) 45, which is suitable as a signal conditioning unit to use the various protocols that the car manufacturers use to operate the OBD2 interface. These are in particular the communication protocol SAE-J1850-VPW 46 employing Ford, the protocol SAE-J 1850-VPWM 47 using GM, the ISO protocol, more specifically the ISO 9141-2 protocol 48, of Toyota and most European car manufacturers, the KWP protocol, more specifically the KWP 2000 protocol 49, which some Hyundai & Mercedes models use, the newer CAN protocol CAN 50, the so-called "Next-Generation Vehicles" (Vehicles from model year 2004), as well as the J 158784 and J170885 protocols used by lorries.

The communication interface 45 is controlled by a CPU 51, which may be ARM7, ARM9, ARM11, Cortex-A5, Cortex-A8, Cortex-A9, Cortex-M0, Cortex-M3 or Cortex-R4. The microprocessor 51 is connected to a clock 12, a GPS module 11 with GPS antenna 52, a memory module 53 having at least one program memory 54 and a data memory 55, a general interface 56 for the connection of peripheral devices, preferably via an RS 232 interface with appropriate driver software, a cellular interface 15, which may be a modem 57 with antenna 58, with cellular SI card for wireless communication with a cellular network 21 (not shown) and a power Rechargeable battery / rechargeable battery management module 13 ^' which is supplied with power from the vehicle battery (not shown) via the OBD2 pin 16 pin 16 and which, in the event of interruption of this power supply, powers the components of the OBD2 adapter ,

The GPS module 11 receives the satellite signals of any G PS system 33 (American NAVSTAR-G PS, European GALI LEO GPS, Russian G LONASS GPS, Chinese AT DOU GPS, not shown) and translates them into GPS coordinates (longitude, latitude). The front-end internal power supply with the power management subsystem 13 and the front-end internal battery 13 ^' ensures that in case of disconnection of the front end 7 from the OBD2 socket 6 of the vehicle 1 (not shown) Data stored in the front-end 7 is not lost due to an interruption of the power supply, which is usually carried out via the OBD2 interface 6 of the vehicle 1.

If required, the following interface devices 56 (not shown) can be connected to the front end via the general interface 56: pressure sensors, acceleration sensors, position sensors, electrical switches, mechanical switches, magnetic switches, optical sensors, photocells, sound measuring devices, sonar devices, radar -Systems, rangefinders, alarm systems, infrared sensors, temperature sensors, gas sensors, scales, ammeters and the like. These peri- pheriegeräte can capture additional vehicle data and / or vehicle states and report to forwarding to the back-end 22 to the front-end 7.

After the gateway 45 or the microprocessor 51 has identified the protocol 46-50, 84, 85 used by the OBD2 system 5 of the vehicle 1, preferably working instructions stored in the program memory 54 control the selection and reading of the vehicle provided by the OBD2 system 5 -specific data and their storage in the data memory 55. If the OBD2 system 5 does not provide GPS coordinates, another, preferably stored in the program memory 54 and executed by the microprocessor 51 work instruction controls the feeding of the GPS module 11 supplied GPS coordinates the stored / to be stored vehicle data. If the OBD2 system 5 does not provide time information, another work instruction, preferably stored in the program memory 54 and executed by the microprocessor 51, controls the electronic date & time stamping of the stored / stored data with the times provided by the clock 12.

For a given reason (eg reaching a certain time, reaching a certain date, external initiation, completion of a refueling operation, establishing a connection with a mobile network, establishing a connection with a peripheral device and the like) controls another, preferably stored in the program memory 54 and the microprocessor 51 executed work instruction the transmission of stored in the data memory 55 vehicle-specific data including the possibly zugeportten GPS coordinates and date & time data or a version thereof via the mobile interface 15, the access 20 to the mobile network and the mobile network 21 to the back-end 22. It goes without saying that in this data transfer usual feedback ensures that the data sent by the OBD2 adapter data are transmitted correctly and completely.

FIG. 14 shows a second embodiment of the front-end 7 which, as in FIG. 13, is connected to the OBD2-BUS 5 of the vehicle 1 (not shown) via a plug-in contact 6/9. Also in this embodiment, which is again only one of many possible execution options, are the components of the front-end 7, which are inserted with his OBD2 father plug 9 in the OBD2 nut socket 6 of the vehicle 1 (not shown) can, shown schematically. The OBD2 socket 6 is supplied with data from the Electronic Control Module (ECM) 41 and / or from the Power Control Module (PCM) 42 of the vehicle 1 (not shown). Via manufacturer-specific PINs (see official PIN assignment of the OBD2 interface), the OBD2 nut socket 6 can also be connected via the vehicle BUS 5 with data from other electronic control units (Electronic Control Units ECU 43, 43 ¹ , 43 ² , 43 ³ ) are supplied.

In the embodiment option of FIGURE 14, the front-end 7 is also an OBD2 adapter. In addition to the usual components, modules and components that has such an OBD2 adapter (see prior art), it includes a housing 44, in which an OBD2 father plug 9 is embedded. It also has a communication interface (gateway) 45, which is suitable as a signal conditioning unit to use the various protocols that the car manufacturers use to operate the OBD2 interface. These are in particular the communication protocol SAE-J1850-VPW 46 employing Ford, the protocol SAE-J 1850-VPWM 47 using GM, the ISO protocol, more specifically the ISO 9141-2 protocol 48, of Toyota and most European car manufacturers, the KWP protocol, more specifically the KWP 2000 protocol 49, which uses some Hyundai & Mercedes models, as well as the newer CAN protocol CAN 50, called Next-Generation Vehicles "(Vehicles from model year 2004) is used, as well as the logs J1587 84 and J1708 85, which are used by trucks. As in FIG. 13, the communication interface 45 is controlled by a CPU 51, which may be ARM7, ARM9, ARM11, Cortex-A5, Cortex-A8, Cortex-A9, Cortex-M0, Cortex-M3, or Cortex-R4 can. The microprocessor 51 is connected to a clock 12, a GPS module 11 with GPS antenna 52, a memory module 53 having at least one program memory 54 and a data memory 55, a general interface 56 for the connection of peripheral devices preferably via a RS 232 interface with corresponding driver software, a Bluetooth chip 17 for wireless close-distance communication with a switching device 61 (not shown), which may be a smartphone 8 (not shown) and a power management module 13 with rechargeable battery / rechargeable battery 13 ^' , which is supplied with power from the vehicle battery (not shown) via the PI N 16 of the OBD2 plug-in contact and which, in the event of interruption of this power supply, supplies power to the components of the OBD2 adapter.

The GPS module 11 receives the satellite signals of any G PS system 33 (American NAVSTAR-G PS, European GALI LEO GPS, Russian G LONASS GPS, Chinese AT DOU GPS, not shown) and translates them into GPS coordinates (longitude, latitude, altitude above sea level). The front end internal power supply 13 with the power management subsystem and the front end internal battery 13 ^' ensures in the event of disconnection of the front end 7 from the OBD2 socket 6 of the vehicle 1 (not shown) in that data stored in the front-end 7 are not lost due to an interruption of the power supply, which is usually effected via the OBD2 interface 6 of the vehicle 1.

If required, the following interface devices 56 (not shown) can be connected to the front end via the general interface 56: pressure sensors, acceleration sensors, position sensors, electrical switches, mechanical switches, magnetic switches, optical sensors, photocells, sound measuring devices, sonar devices, radar -Systems, rangefinders, alarm systems, infrared sensors, temperature sensors, gas sensors, scales, ammeters and the like. These peripheral devices may capture supplemental vehicle data and / or vehicle conditions and report to the front end 7 for forwarding to the back end 22.

After the gateway 45 or the microprocessor 51 has identified the protocol 46-50, 84, 85 used by the OBD2 system 5 of the vehicle 1 (not shown), preferably work instructions stored in the program memory 54 control the selection and reading of the messages from the OBD2 system. System 5 provided vehicle-specific data and their storage in the data memory 55. If the OBD2 system 5 does not provide GPS coordinates controls another, preferably stored in the program memory 54 and executed by the microprocessor 51 working instructions supplied by the GPS module 11 supplied GPS coordinates to the stored / stored vehicle data. If the OBD2 system 5 does not provide time information, another work instruction, preferably stored in the program memory 54 and executed by the microprocessor 51, controls the electronic date & time stamping of the stored / stored data with the times provided by the clock 12.

For a given reason (eg reaching a certain time, reaching a certain date, external initiation, completion of a refueling operation, establishing a connection with a switching device 61, establishing a connection with a peripheral device and the like) controls another, preferably stored in the program memory 54 and The work instruction executed by the microprocessor 51 includes the transmission of the vehicle-specific data stored in the data memory 55, including possibly transmitted GPS coordinates and date & time data or a version thereof via the Bluetooth interface 17 to the likewise Bluetooth-enabled switching device 61 of course, that in this data transmission usual feedback si- ensure that the data sent by the OBD2 adapter is transmitted correctly and completely.

FIG. 15 shows a third embodiment of the front-end 7 which, as already shown in FIG. 13, is connected via a plug-in contact to the OBD2-BUS 5 of the vehicle 1 (not shown). Also in this embodiment, which is also only one of many possible execution options, the components of the front-end 7, which are inserted with its OBD2 father plug 9 in the OBD2 nut socket 6 of the vehicle 1 (not shown) can, shown schematically. The OBD2 socket 6 is supplied with data from the Electronic Control Module (ECM) 41 and / or from the Power Control Module (PCM) 42 of the vehicle 1 (not shown). Via manufacturer-specific PINs (see official PIN assignment of the OBD2 interface), the OBD2 nut socket 6 can also be connected via the vehicle BUS 5 with data from other electronic control units (Electronic Control Units ECU 43, 43 ¹ , 43 ² , 43 ³ ) are supplied.

In the embodiment option of FIGURE 15, the front-end 7 is also an OBD2 adapter. In addition to the usual components, modules and components that has such an OBD2 adapter (see prior art), it includes a housing 44, in which an OBD2 father plug 9 is embedded. It also has a communication interface (gateway) 45, which is suitable as a signal conditioning unit to use the various protocols that the car manufacturers use to operate the OBD2 interface. To avoid repetition, reference is made to the descriptions relating to FIGURES 13 and 14 in this regard.

As in FIGS. 13 and 14, the communication interface 45 is controlled by a CPU or microprocessor 51 comprising an ARM7, ARM9, ARM11, Cortex-A5, Cortex-A8, Cortex-A9, Cortex-MO, Cortex-M3 or Cortex-R4. The microprocessor 51 is connected to a clock 12, a memory module 53 having at least one program memory 54 and a data memory 55, a general interface 56 for the connection of peripheral devices, preferably via an RS 232 interface with corresponding driver software, a WiFi WLAN interface 14 for wireless communication either with a switching device 61 (not shown), which may be a smartphone 8 (not shown), or for wireless communication with access to the Internet 18 (not shown) and the Internet 19 (FIG. Not shown). In addition, the front end has a power management module 13 with rechargeable battery / battery 13 ^' , which is supplied via the PIN 16 of the OBD2 plug contact with power from the vehicle battery (not shown) and in the case of interruption of this power supply the components of the OBD2 adapter are powered. The power supply 13 is arranged as shown in FIGS. 13 and 14 and functions as set forth in the description of these figures.

Via the general interface 56, a peripheral device 86 is connected to the front-end 7. This peripheral device 86 has a GPS module 87 with GPS antenna 88 or is connected to an external GPS module 11. The peripheral device 86 is adapted to transmit current GPS coordinates to the front-end 7 as needed.

If required, the following interface devices 56 (not shown) can be connected to the front end via the general interface 56: pressure sensors, acceleration sensors, position sensors, electrical switches, mechanical switches, magnetic switches, optical sensors, photocells, sound measuring devices, sonar devices, radar -Systems, rangefinders, alarm systems, infrared sensors, temperature sensors, gas sensors, scales, ammeters and the like. These peripheral devices may capture supplemental vehicle data and / or vehicle conditions and report to the front end 7 for forwarding to the back end 22. After the gateway 45 or the microprocessor 51 has identified the protocol 46-50, 84, 85 used by the OBD2 system 5 of the vehicle 1 (not shown), preferably work instructions stored in the program memory 54 control the selection and reading of the messages from the OBD2 system. System 5 provided vehicle-specific data and their storage in the data memory 55. If the OBD2 system 5 does not provide GPS coordinates controls another, preferably stored in the program memory 54 and executed by the microprocessor 51 working instructions supplied by the peripheral device 86 GPS coordinates to the stored / stored vehicle data. If the OBD2 system 5 does not provide time information, another work instruction, preferably stored in the program memory 54 and executed by the microprocessor 51, controls the electronic date & time stamping of the stored / stored data with the times provided by the clock 12.

For a given reason (eg reaching a certain time, reaching a certain date, external initiation, completion of a refueling operation, establishing a connection with a switching device 61, establishing a connection with a peripheral device and the like) controls another, preferably in the program memory 54 and stored by the microprocessor 51st executed work instruction the transmission of the vehicle-specific data stored in the data memory 55 including the transmitted GPS coordinates and date & time data or a version thereof via the WiFi / WLAN interface 14 either to a switching device 61 (not shown) which is a smartphone 8 may be (not shown), or access to the Internet 18 and the Internet 19. It goes without saying that in this data transmission usual feedback ensures that the data sent by the OBD2 adapter data is transmitted correctly and completely.

FIG. 16 shows a fourth, simplified embodiment of the front-end 7, which, as already shown in FIG. 13, is connected to the OBD2-BUS 5 of the vehicle 1 (not shown) via a plug-in contact 6/9. Also in this embodiment, which is also only one of many possible execution options, the components of the front-end 7, which are inserted with his OBD2 father connector 9 in the OBD2 nut socket 6 of the vehicle 1 (not shown) can, shown schematically. The OBD2 socket 6 is supplied with data from the host computer 43 of the OBD2 system of the vehicle 1 (not shown). The role of the host computer may be assumed by an Electronic Control Module (ECM) 41 (not shown) and / or a Power Control Module (PCM) 42 (not shown). About manufacturer-specific occupied PINs (see official PIN assignment of the OBD2 interface), the OBD2 nut socket 6 via the vehicle BUS 5, if necessary, with data from other electronic control devices (Electronic Control Units ECU 43, 43 ¹ , 43 ² , 43 ³ ) are supplied.

In the embodiment option of FIGURE 16, the front-end 7 is also an OBD2 adapter, but one with only limited communication capability. It has neither a mobile phone nor a Bluetooth interface, nor a WiFi / WLAN interface. In addition to the usual components, modules and components that has such an OBD2 adapter (see prior art), it includes a housing 44, in which an OBD2 father plug 9 is embedded. It also has a communication interface (gateway) 45, which is suitable as a signal conditioning unit to use the various protocols that the car manufacturers use to operate the OBD2 interface. To avoid repetition, reference is made to the descriptions relating to FIGURES 13 and 14 in this regard.

As in FIGS. 13 and 14, the communication interface 45 is controlled by a CPU or microprocessor 51 comprising an ARM7, ARM9, ARM11, Cortex-A5, Cortex-A8, Cortex-A9, Cortex-MO, Cortex-M3 or Cortex-R4. The microprocessor 51 is connected to a clock 12, a memory module 53 having at least one program memory 54 and a data memory 55, a general interface 56 for the connection of peripheral devices preferably via an RS 232 interface with appropriate driver software. In addition, the front end has a power management module 13 with rechargeable battery / battery 13 ^' , which is supplied via the PI N 16 of the OBD2 plug contact with power from the vehicle battery (not shown) and in the case of interruption of this Power supply the components of the OBD2 adapter powered. The power supply 13 is arranged as shown in FIGS. 13 and 14 and functions as set forth in the description of these figures.

Via the general interface 56, a peripheral device 86 is connected to the front-end 7. This peripheral device 86 has a GPS module 87 with GPS antenna 88 or is connected to an external GPS module. The peripheral device 86 is adapted to transmit current GPS coordinates to the front-end 7 as needed.

After the gateway 45 or the microprocessor 51 has identified the protocol 46-50, 84, 85 used by the OBD2 system 5 of the vehicle 1 (not shown), preferably work instructions stored in the program memory 54 control the selection and reading of the messages from the OBD2 system. System 5 provided vehicle-specific data and their storage in the data memory 55. If the OBD2 system 5 does not provide GPS coordinates controls another, preferably stored in the program memory 54 and executed by the microprocessor 51 working instructions supplied by the peripheral device 86 G PS coordinates to the saved / stored vehicle data. If the OBD2 system 5 does not provide time information, another work instruction, preferably stored in the program memory 54 and executed by the microprocessor 51, controls the electronic date & time stamping of the stored / stored data with the times provided by the clock 12.

The transmission of the vehicle-specific data stored in the data memory 55, including the GPS coordinates and time data or a version transmitted, takes place neither via a communications network (Internet 19, mobile radio network 21) nor via a wireless connection, but via the OBD2 connector 9 of the front-end 7 and an external OBD2 socket connected to an external device 86 (not shown) or device combination 86 ^' (not shown) suitable for storing the vehicle-specific data stored in the front-end 7 or read a version thereof from the front-end 7 and forward it to the back-end 22. Such a device 86 (not shown) may be an external vehicle diagnostic device connected to the Internet 19, and the data read from the front-end 7 or a version thereof via the Internet 19 to the back-end 22 transfers. Such a device 86 (not shown) may also be a PC or other communication terminal (laptop, tablet, smartphone, server or the like) to which such an OBD2 socket is connected. The external vehicle diagnostic device, the PC or the other communication terminal may be connected to a communication network other than the Internet 19 (cable network, telephone landline, cellular network 21, intranet, data link system or the like) and may be from the front -End 7 transmitted data or a version thereof via this other communication network to the back-end 22. Accordingly, the front-end 7 requires neither a Bluetooth interface 17 nor a mobile radio interface 15, nor a SIM card slot 16, nor a SIM card 16 ^' , nor an antenna 58 nor a WiFi / WLAN interface 14th

It is possible, for example, that the front-end 7 with its OBD2 father plug 9 is disconnected after one month from the OBD2 nut socket 6 of the OBD2 system 5 of the vehicle 1 (not shown) and to another OBD2 nut Socket is plugged into a PC, which in turn is connected to the Internet 19. This approach is enabled by the internal power supply 13 of the front-end 7: it can be disconnected from the OBD2 socket of the vehicle 1 (not shown) without loss of data. The prevention of data loss is also possible through front-end internal storage on a medium or module (e.g., a flash SSD) whose storage capacity is independent of a constant power supply to the front-end.

The PC has software that is capable of communicating with the front-end 7 and read data from the front-end 7, if necessary, to perform data analysis. The read out of the front-end data or a version thereof are transmitted from the PC via the Internet 19 to the back-end 22. Instead of a PC, an external vehicle diagnostic device / system or another communication terminal can also be used (see above).

FIG. 17 schematically shows the installation of a front-end 7, which is equipped with a mobile radio interface 15, a mobile radio card slot of a mobile radio card (SIM card) 16 and a general interface 56. The front-end 7 is plugged with his OBD2-father plug 9 on the OBD2 nut socket 6 of a passenger car 1, which is usually positioned below the dashboard. It is also connected via its general interface 56 and cable 214 to an external navigation device 85 having a GPS module 87 and a GPS antenna 88. Since the front-end 7 has its own mobile radio interface 15, it can communicate directly with the back-end 22 (not shown) via access to the mobile radio network 20 (not shown) and mobile radio network 21 (not shown). It is thus independent of a switching device 61 (not shown) or of a smartphone 8 (not shown) and can transmit the data at any time to the back-end 22 (not shown).

FIG. 18 shows a schematic representation of a second embodiment of the installation of a front-end 7 on the OBD2 socket 6 of a passenger vehicle 1. The front-end 7 is connected to a GPS module 11, a mobile radio interface (modem) 15, a mobile radio Card slot and a mobile card (SIM card) 16 equipped. The front-end 7 is plugged with his OBD2-father plug 9 on the OBD2 nut socket 6 of a passenger car 1, which is usually positioned below the dashboard. Since the front-end 7 has its own GPS module 11, it needs neither an external navigation device 85 (not shown) nor a general interface 56 (not shown). In addition, because the front-end 7 has its own cellular interface 15, it can communicate directly with the back-end 22 (not shown) via access to the cellular network 20 (not shown) and cellular network 21 (not shown) , It is thus independent of a switching device 61 (not shown) or of a smartphone 8 (not shown) and can transmit the data at any time to the back-end 22 (not shown).

FIG. 19 shows a diagram of a third embodiment of the installation of a front-end 7 on the OBD2 socket 6 of a passenger car 1. The front-end 7 is equipped with a GPS module 11 and a Bluetooth interface 17. The front end 7 is plugged with his OBD2 father connector 9 on the OBD2 socket 6 of a passenger car 1, which is usually positioned below the dashboard. Via its Bluetooth interface 17, the front-end 7 connect wirelessly with a Bluetooth-enabled smartphone 8, which has a Bluetooth interface 17 ^' , is without GPS function and acts as a switching device 61, as long as it is in the vicinity of the vehicle 1. Since the front-end 7 has its own GPS module 11, it does not require an external navigation device 85 (not shown) or a general interface 56 (not shown) for this navigation device. Without its own WiFi / WLAN interface 14 (not shown) and without its own mobile modem 15 (not shown), the front-end 7 has no possibility to connect directly to the Internet 19 (not shown) or to a mobile network 21 dial in (not shown). It therefore requires a switch 61 (not shown) which receives the data packet addressed to the back end 22 (not shown) from the front end 7 and with or without buffering via Internet access 18 (not shown) and Internet 19 (not shown) ) or via cellular network access 20 (not shown) and cellular network 21 (not shown) to the back end 22 (not shown). For this purpose, the switching device 61 or the smartphone 8 requires, in addition to the Bluetooth interface 17 ^' for communication with the front end 7, either a Wi-Fi / WLAN interface 14 ^' (which has a smartphone 8 id.) And / or a mobile radio interface 15 ^' with SIM card slot and SIM card 16 ^' , which each smartphone 8 has.

FIG. 20 shows a schematic representation of a fourth embodiment of the installation of a front-end 7 on the OBD2 socket 6 of a passenger vehicle 1. The front-end 7 is plugged onto the OBD 2 nut socket 6 of the OBD 2 system 5 of the vehicle 1 and as in FIG 19 equipped with a Bluetooth interface 17, but it has neither its own GPS module 11 (not shown) nor a WiFi / WLAN interface 14 (not shown) nor a mobile modem 15 (not shown ). Thus, the front-end 7 has no way to dial directly into the Internet 19 (not shown) or in a mobile network 21 (not shown). To compensate for this deficit, it can connect wirelessly to a Bluetooth-enabled smartphone 8, which acts as a switching device 61 as long as it is in the vicinity of the vehicle 1. Since the smartphone also has a GPS function (and correspondingly a GPS module 36) in addition to the Bluetooth interface 17 ^' , it can deliver the GPS coordinates to the front end 7 when it is needed and when it is needed near the vehicle 1 is. Both the smartphone 8 and the front-end 7 are enabled via a special software app to make this communication from the smartphone 8 to the front-end 7.

When data is to be transmitted to the back-end 22, the front-end 7 establishes and transmits a wireless Bluetooth connection with the smartphone 8. The smartphone 8 can then send the data received from the front-end 7 immediately or with a time delay to the back-end 22 and via Internet access 18 and the Internet 19 or via a mobile access 20 and a mobile network 21, as it equipped with both a WiFi / WLAN interface 14 ^' and with a mobile communication interface 15 ^' .

FIG. 21 schematically illustrates a fifth embodiment of the installation of a front end 7 with its OBD2 father plug 9 on the OBD2 nut socket 6 of a passenger car 1. The front end 7 is provided with a WiFi / WLAN interface 14 and a GPS module 11. Thus, no GPS coordinate providing peripheral device 86 (not shown) is needed. The front-end 7 can optionally connect via WiFi / WLAN to a switching device 61 (a smartphone 8) or directly to the Internet 19 and transmit the data records in accordance with address back-end 22. Advantage of the smartphone 8 is that incurred for the operator of the front-end 7 and the system according to the invention no communication costs, this carries the owner of the smartphone 8. Advantage of a direct transfer of data via the Internet 19 is that the front-end remains independent 8. Since refueling data are not generated as often and their evaluation is not time-critical, it is usually possible to wait until the front End 7 can connect to a (shared) Internet access 18 (not shown) and thus to the Internet 19 (not shown).

FIG. 22 shows a schematic representation of a sixth embodiment of the installation of a front end 7 with its OBD2 male connector 9 on the OBD2 nut socket 6 of a passenger vehicle 1. A smartphone 8 is present in the vehicle 1, which is connected via a WiFi network. WLAN interface 14 ^' , a mobile communication interface 15 ^' with SIM card slot and SIM card 16 ^' and a Bluetooth interface 17 ^' has. The front-end 7 has a WiFi / WLAN interface 14, a Bluetooth interface 17, a mobile modem 15, a mobile radio card slot 16 and a mobile radio card (SIM card) 16 ^' and a GPS module 11 fully equipped. It is thus independent of external GPS modules and has full freedom of choice with regard to communication with the back-end 22, ie all 6 communication paths are possible:

1.) Mobile modem 15 - Mobile network access 20 - Mobile network 21 - Back-end 22;

2.) WiFi / WLAN Interface 14 - Internet Access 18 - Internet 19 - Back End 22;

3.) WiFi / WLAN interface 14 - Smartphone 8 - Internet access 18 - Internet 19 - Back-end 22;

4.) WiFi / WLAN interface 14 - Smartphone 8 - Access mobile network 20 - Mobile network

21 - back-end 22;

5.) Bluetooth Interface 17 - Smartphone 8 - Internet Access 18 - Internet 19 - Back End 22;

6.) Bluetooth interface 17 - Smartphone 8 - Access mobile network 20 - Mobile network

21 - back-end 22.

In FIGURE 23, a variant embodiment of the process of obtaining refueling data sets 190 in a flow chart is shown schematically. It is assumed that the registration, installation and commissioning of the front-end 7 as shown in FIG 12 is completed, that the front-end 7 is plugged with its OBD2 connector 9 on the OBD2 socket 6 of the vehicle 1 and the data supplied by OBD2 system 5 (see block 91). There is a work instruction and a clock 12 running every 15 seconds to initiate the work instruction (block 92). This work instruction consists first in the query of the revolution sensor 3 of the vehicle 1 (block 93). If this indicates a speed of> 0, the flow goes back to before the step 92. If the revolution sensor indicates a speed of 0, the flow proceeds to block 94, which includes the inquiry as to whether the tank level (TFS) in one of the Fuel tanks rising (CNG vehicles, dual-fuel vehicles and plug-in vehicles each have two tanks, logic: tank level> 15 seconds earlier). If not, the flow goes back to before step 92. If so, flow proceeds to block 95, whose work instruction is to save the process as a start of refueling (BA). The storage of the start of refueling includes the storage of the data tank, tank level, odometer reading, GPS coordinates, date and time. If the tank level (TFS) of the tank level sensor 2 is not specified as a liter number, the front end 7 converts the level indication into a number of liters before storing the corresponding value by means of a separate work instruction.

After the start of refueling (BA) has been stored, the query is made in block 96 as to whether a time of 10 seconds has elapsed. If this is not the case, the process goes back to the Abiaufschritt 96. If 10 seconds have expired, in block 97, the query is made whether the tank level is still rising (logic: tank level> than 10 seconds before). If this is the case, the process goes back to the Abiaufschritt 96. If this is not the case, the process continues to block 98, whose work instruction is to save the process as refueling end (BE). The Storage of refueling end includes storage of data tank, tank level, odometer reading, GPS coordinates, date and time. If the tank level of the Tankfüllstand- Sensor 2 is not specified as a liter number, the front-end 7 makes before the storage of the corresponding value by means of a separate work instruction, a conversion of the level indication into a liter number. Upon completion of this work instruction, flow proceeds to block 99, whose work instruction is to initiate the transfer of the two stored records to the back end 22. Thereafter, the process returns to block 92.

FIG. 24 shows an execution option of raw refueling records 102 of a vehicle 1. This may be performed in the front-end 7, in the smartphone 8, or in the back-end 22. Shown is an extract of the raw refueling and tank level data 150 of a single vehicle 1 incurred in a calendar month in April 2016. This data extract can be created for all vehicles that are connected to the system according to the invention - which can be several million per country or state. The raw data 150 is stored in the vehicle file / database 30 of the back-end 22 in this exemplary embodiment, the vehicle-specific content of which is here extracted and, for example, shown. The vehicle-specific data can be stored in this or similar manner a also in the front-end 7 or in the switching device 61 and possibly also evaluated (but then only at the vehicle level, because it lacks the data of the other vehicles 1) , These alternative execution options are not further elaborated here, since the function (logic and systematics of the solution of the task "representation of raw data") basically remains the same and is obvious to a person skilled in the art after having read the invention.

The extract from the raw data 150 includes one or more headers 101 and the data region 102 in which the individual data records are listed. In the at least one header 101, the individual column names are listed, first the vehicle identification number 103 from the vehicle registration certificate (field E), the check digit 104 for the vehicle identification number 103 from the vehicle registration certificate (field 3 ), the fuel main type (KHA) or energy source (EQ) 105 from the vehicle bill (field P.3), the identification number 106 of the front-end 7, the software version 107 of the front-end 7 with the record has been created, the record number 108 of the front-end 7, the cause 109 for the generation of the record, the date 111 at the time of record generation, the time stamp 112 at the time of record generation, the tank fill level of the tank 1113 at the time of the record generation, the tank level of the tank 2114 at the time of the record generation, the GPS length coordinate 115 at the time of the record generation, the GPS width coordinate 116 at the time of record generation, d en odometer 117 at the time of data set generation, day mileage 118, daytime mileage 119, which vehicle 1 traveled that day in fuel main mode 1, and daily mileage 121, which was used by vehicle 1 on that day Has completed the main fuel type 2.

The vehicle I D number 103 is the vehicle ID from the vehicle license. The check digit 104 is used to check whether the vehicle I D 103 has been stored without errors. To save space, the column contents in data area 102 are partially encoded. For example, the contents of the reason column 109 are coded. The code "BB" means start of refueling, the code "BE" refueling end and the code "TA" end of day The end of the day (the generation of a daily statement record) is required at the beginning and at the end of a period causally fair demarcation of the route It goes without saying that in addition to this, other occasions can be defined for the generation of data records and correspondingly more data can be collected, such as the start-up and start-up switching off of the engine, the occupancy of one or more seats, the loading of the vehicle, full braking, high accelerations, engine revving, accidents, the deployment of airbags, disconnecting the vehicle battery, switching off the exhaust aftertreatment, the air volume flow, the air mass flow, the Exhaust gas volume flow, the exhaust gas mass flow, the outside temperature, the oil temperature, the cooling water temperature, the tire pressure, etc. etc. Instead of the tank levels 113, 114 and states of charge of batteries (not shown) can be specified. The continuous counting of the records using the front-end record number 108 serves to check or detect tampering. The tank levels 113, 114 with the main fuel types 113 ^' and 114 ^' are already converted into liters. The partial representation of the raw data 150 shown here is only one of many display options. Other representations of the raw data 150 and processed data 150 ^' are considered to be within the scope of the invention.

The tank 2 and its fill level 114 with the main fuel type 114 ^' are listed because there are vehicles that use two different fuel main types 113 ^' and 114 ^' . So most CNG vehicles are bivalent or even monovalent + designed, ie, they can use both gasoline and CNG as fuel. Accordingly, plug-in vehicles use electric power (which is considered fuel here) and gasoline. There are also some plug-in vehicles that use electric power and diesel (some Volvo models). There are also so-called dual-fuel vehicles (mainly trucks) that use diesel and CNG or diesel and LNG as fuel. There are also trucks that use CNG and LNG as fuel. It is understood that fuel consumption, energy input and (LCA) GHG emissions are calculated separately for each of the main fuel types 113 ^' , 114 ^' when using two main fuel types 113 ^' and 114 ^' . If the respective results are known, these are combined and summation and average values are calculated.

In the procedure described above, neither fuel-type-of-fuels nor fuel-type specific fuel consumption, energy inputs, or (LCA) GHG emissions can be determined. To get to these, it must be noted which route is covered with which fuel main species. This can be done in the front-end 7 in the form of software deposited work instruction. Basically, there are several options for the design of this work instruction. A first option may be that the front-end 7 logs every change of fuel supply according to a work instruction and forms a record for it. In the record field "Occasion 109", the change to the new fuel type is noted as a reason for the generation of the data record, for example "change to CNG" as WaCNG. As usual, this data record is transferred to the back-end 22, which carries out the further analysis of this data record type. A second option may be that the front-end 7 determines according to the stored in software work instruction, which day driving distance has covered the vehicle 1 and what proportion of the main fuel types on the daily routes had. For this purpose, the corresponding front-end algorithm only has to determine and store the changes of the main fuel type 215 and to determine and store the respective odometer reading. From this data, the algorithm of the front-end 7 calculates the respective daily kilometer shares. The results supplement the daily data records. This second option is shown in the embodiment of FIG. Other options for determining the main fuel type 215 and / or fuel grade specific fuel consumption, energy inputs, and (LCA) GHG emissions are possible, but will not be discussed further here, since they will be made by one of ordinary skill in the art after having understood the invention can.

From the example of the FIGU R 24 can be seen in the records 852/853, 862/863, 874/875 and 878/879 that the vehicle 1 with the ID JTDBS182200042121 in the month April 2016 4 times tanked Has. The other records refer to the daily statements. It can be seen from the GPS coordinates 115, 116 that the vehicle 1 was parked at the same location at 24 o'clock, presumably in its usual location (in the garage). From GPS coordinates 115, 116, it can also be seen that in April 2016, except on the 21st of the month, it did not move very far from its usual location.

The raw data 150, 160 can in principle also be evaluated by the back-end 22, by the switching device 61 or by the front-end 7. Since data from "living" files or databases are required for the calculation of the GHG emissions (fuel file / database 31, gas station file / database 32), ie data that is constantly changing, it is advantageous to the evaluation centrally in the back-end 22 to make, otherwise a large number of decentralized front-ends 7 and / or switching equipment 61 would have to be updated or maintained continuously, which means an avoidable effort.

The vehicle-specific evaluation of the data sets is dependent on the design of the algorithm used (in a variety of vehicles participating in the system according to the invention, there are of course a variety of other evaluations and aggregations, which are not described here in detail, as they the usual level of knowledge Skilled in the industry). In order to determine the distance covered by the vehicle 1 in the month of April 2016, the evaluation algorithm of the back-end 22 can, for example, from the raw data 150, the kilometer count from the last day of the previous month from the kilometer count of the last day of the current month su The 74.803 km of data record 845 is taken from the 76.564 km of record 883. The result of 1.761 km serves as the basis for the further calculations.

To determine the fuel consumption of the vehicle 1 in the month of April 2016, the evaluation algorithm of the back-end 22 for this vehicle 1, for example vehicle and period specific from the raw data 150, the difference between the tank level at the end of the last day of the previous month (the in the example shown here is 39.9 liters) and calculate the tank level at the end of the last day of the current month (36.6 liters). In this example, there is a decrease in fuel stock of 3.3 liters. This inventory decrease shall be added to the fuel quantities fueled in the relevant period, ie the 56.2 liters from 07.04.2016, the 49.0 liters from 15.04.2016, the 20 liters from 25.04.2016 and the 59.6 liters from 27.04.2016 that add up to 184.8 liters. In total - ie including the inventory inspection - the vehicle with the vehicle I D JTDBS182200042121 in the month of April 2016 thus consumed 188.133 liters. This results in an average consumption of 0.10683 liters per kilometer or 10.683 liters per 100 km for the month of April 2016.

The determination of lifecycle emissions is more complex. For this purpose, it must first be known which fuel type the driver has fueled. Although the main fuel type 105 results from the vehicle license, it remains unknown at first which fuel type was fueled. In the case of gasoline vehicles, e.g. the fuel sub-types Super, Super E5, Super E10, E85 and Super Plus to choose from. As long as it can not be determined, either the back-end 22 may operate at weighted averages which are periodically determined across all gasoline subtypes and entered into the fuel database 31, or the front-end 7 will query the fueled one Fuel subspecies that is projected on the smartphone 8 (or the switching device 61) and the driver answers after refueling his vehicle 1.

In the example shown here, it is possible to determine the fuel subtype via a comparison between the refueling location and the specific refueling station data. To the fuel subspecies too First, the algorithm has to identify the gas stations where fueling was done. This is done via an adjustment of the GPS coordinates 115, 116. From the data sets 852/853, 862/863, 874/875 and 878/879 the refueling locations are known via the GPS coordinates 115, 116, namely for refueling on 07.04 .2016 the Gulf gas station in Paterswoldseweg 139, 9727 Groningen, The Netherlands, for the refueling on 15.04.2016 the Esso gas station in the Kanaalstraat 22A, 8601 GA Sneek, for the refueling on 25.04.2016 again the Gulf gas station in Paterswoldseweg 139 , 9727 Groningen, The Netherlands, and for the refueling on 27.04.2016 the Shell petrol station in De Vennen 178, 9934 AJ Delfzijl, the Netherlands. From the gas station database 32, the algorithm of the back-end 22 learns that at these 4 identified gas stations according to gas station database entry in April 2016, no Super E5 was delivered and no Super E10, but only the fuel subspecies "normal, unleaded super gasoline ".

Now that the refueled fuel subtypes are known ("normal, unleaded super-gasoline" in all 4 cases), the algorithm retrieves from the fuel database 31 the lower calorific value that the fuel subtype "normal, unleaded super-gasoline -Benzin "in April 2016 in the north of the Netherlands. That was 8.770 kWh _H i / liter. The vehicle 1 had thus in April 2016 an energy input of 188.133 liters x 8.770 kWh _Hi / liter = 1,649.93 kWh _Hi . It goes without saying that the procedure remains the same even if a different fuel subspecies is fueled with each refueling.

Since both the fuel subtype and the energy input are known, the algorithm from the fuel database 31 can query the fuel-subsistence-specific life-cycle emission related to an energy unit (MJ or kWh _H i). In April 2016, this value for the fuel subtype "Normal unleaded super gasoline" was around 335.9 gC0 ₂ equivalents per kWhui (it goes without saying that the procedure remains the same even if every refueling For the energy input of 1,649.93 kWh _H i, this results in an effective LCA-THG emission of 554.210 kg C0 _2- eq. Converted to the kilometer this is 554.210 gC0 ₂ /1.717 km = 323 gC0 ₂ / km The officially determined stoichiometric value for this vehicle according to the vehicle registration certificate is 234 gC0 ₂ / km The difference between the official stoichiometric value and the effective LCA emission thus amounts to 89 gC0 ₂ / km or + 38%.

FIGURE 25 shows, for illustration 160 of FIGURE 24, an alternative representation 200 of the raw data sets 102 of a vehicle 1 as transmitted to the back-end 22. In principle, however, they can also be routed in the front-end 7 or in the smartphone 8 (or in the switching device 61) and used there for further calculations. A distinction is made between data sets with raw data, as generated by the front end 7 (and possibly also partly by the switching device 61 or external peripherals 86), and processed data sets that are processed by the algorithm according to the invention (see below) and supplemented with calculation results were.

Shown is an extract of the raw refueling and tank level data 200 of a single vehicle 1 accumulated in the first week of the April 2016 calendar month and transmitted to the back-end 22. This data extract can be created in the same way for all vehicles 1 that are connected to the system according to the invention - which can be several million per country or state. The raw data 200 are initially stored in this raw state in the vehicle file / database 30 of the back-end 22 in this embodiment. In a second step, these raw data sets are supplemented with calculation results and stored as finished calculated data records in the vehicle database 30. However, it is also possible to have the raw records immediately (or after a short staging) from below to have the described algorithm processed and to store only finished data sets in the vehicle file / database 30.

The vehicle-specific data can be stored in this or similar manner but also in the front-end 7 or in the switching device 61 and possibly also evaluated (but then only at the vehicle level, because it lacks the data of the other vehicles 1) , These alternative execution options are not further elaborated here, since the function (logic and systematics of the solution of the task "representation of raw data") remains basically the same and is obvious to a person skilled in the art after having read the invention.

The extract of the raw data 200 includes one or more headers 101 and the data region 102 in which the individual data sets are listed. In the at least one header 101, the i.d.R. consistent vehicle holder data (not shown) may be listed, e.g. the vehicle ID 103, the check digit 104, the official fuel master 105, the front-end ID 106, the front-end software 107, the license plate of the vehicle (not shown), the holder of the vehicle (not shown) , its address and communication data (not shown), the ID of the vehicle owner (not shown), error messages (not shown), TUV expiration date (not shown), etc. In the simplified illustration 200 shown here, only the ones relevant in this context are Column names are listed, first the record number 108 of the front end 7, the record generation record 109, the record generation date 111, the record generation time stamp 112, the respective fuel - Main type 215, the tank level of the tank 1 113 at the time of data set generation, the tank level of the tank 2 114 at the time of data set generation and the odometer 117 at the time point t the record generation. For clarity, in this embodiment, the GPS length coordinate 115 and the GPS width coordinate 116 are omitted. With regard to these data fields, the above statements made to FIG. 24 apply.

The data sets of the raw data representation 200 are numbered in order to be able to determine possible manipulations. To save space, the column contents in data area 102 are partially encoded. Thus, e.g. encodes the contents of the reason column 109. The code "BB" means refueling start, the code "BE" refueling end, the code "M-an" engine on, the code "M-off" engine off, the code "WKA" change of fuel type and the code "TA "Daily closing. The daily closing according to the invention (the generation of a daily closing data set) is required in order to be able to make a causal demarcation of the driving distance and the fuel consumption at the beginning and at the end of a period and, based on this, a causal demarcation of the energy input and the GHG emissions. It goes without saying that, in addition, further occasions for the generation of data records can be defined and correspondingly further data can be collected, such as data. the starting and stopping of the engine, the occupancy of one or more seats, the loading of the vehicle, full braking, high accelerations, engine revving, accidents, the deployment of airbags, disconnecting the vehicle battery, switching off the exhaust aftertreatment, the air volume flow, the air mass flow, the exhaust volume flow, the exhaust gas mass flow, the outside temperature, the oil temperature, the cooling water temperature, the tire pressure, etc. etc. Instead of the tank levels 113, 114 and states of charge of batteries (not shown) can be specified.

As fuel main types 118, only the codes "Benz" for gasoline and "CNG" for compressed natural gas are listed in this embodiment variant, but it goes without saying that any number of other codes for other main fuel types 215 can be displayed. For example, you can Among others, the codes "Dies" for diesel, "LNG" for liquefied natural gas, "LPG" for liquefied petroleum gas, "Electricity" for electric power and "H2" for hydrogen gas are used Refueling data of a bivalent CNG vehicle are listed in tank 1 CNG and tank 2 in gasoline (petrol) The fill levels 113 of tank 1 are given in kg and the fill levels 114 of tank 1 in liters.

In contrast to embodiment variant 160 of FIG. 24, in this embodiment variant 200 of FIG. 25 the front end 7 is not only programmed to generate a data record at the occasions "start of refueling", "refueling end" and "end of day", but additionally also on the occasions "engine on", "engine off" and "fuel type change". This advantageously makes it possible to break up the use of the vehicle 1 into trips which can be analyzed individually.

The vehicle 1 shown here is a bivalent CNG vehicle that is used by a frequent driver. For technical reasons (eg prevention of freezing of the CNG pressure reducer, which is heated with the approximate 80 ° C "cooling water" of the warm engine), the vehicle is always warmed up with petrol after the engine has started This and other fuel changes are logged by the front-end 7. Shown are the relevant raw data of the first week of April 2016. From this raw data can be derived according to the invention a variety of secondary and tertiary data, which ultimately lead to the (LCA) GHG emissions caused by this frequent driver.

From the comparison of the data fields 117 of the first and last record of the period, namely record 1653 and record 1728, which are a subset of the records 102, one can easily determine which route the vehicle 1 in the week from 01.04.2016 to 07.04. 2016 has covered: 1,594.9 km.

As you can also easily see, the driver of the vehicle in this first week of April has been refueled 5 times, namely 21.152 kg of the main fuel CNG on 03/04/2016 (records 1672/1673), secondly 17,304 liters of the main fuel gasoline also on 03.04.2016 (1676/1677), third, 20.916 kg of the main fuel CNG on 04.04.2016 (1686/1687), fourth, 20.441 kg of the main fuel CNG also on 04.04.2016 (1695/1696) and fifth 17,477 kg the main fuel type CNG on 06.04.2016 (1716/1717).

In addition, it is known that the filling level of CNG tank 1 at the beginning of the week was exactly 9,500 kg and the filling level of gasoline tank 2 was exactly 11,490 liters (see data set 1653). By the end of the week, the CNG tank 1 level had dropped to 6.146 kg and the gasoline tank 2 level had risen to 16.037 liters (see record 1728). From this data, the fuel consumption can be calculated, but only by main fuel type: The main fuel type CNG there was between the beginning of the week and weekend a reduction in stock (fuel consumption) of 9,500 kg ./. 6.146 kg = 3.354 kg. In addition, a total of 79.986 kg of the main fuel type CNG were fueled, resulting in the period considered a total fuel consumption of 83.310 kg. For the main fuel type gasoline, there was a stock build-up of 16,037 liters between the beginning of the week and the weekend. 11,490 liters = 4,547 liters, deducted from the quantity of petrol (17,304). The gas consumption was thus 17,304 liters ./. 4,547 liters = 12,757 liters.

Using only averages for data analysis can easily calculate energy input and LCA-GHG emissions. From the fuel database 31 it is then known that the fuel CNG has on average a (lower) calorific value Hi of 13.393 kWh _H i / kg and gasoline has on average a (lower) calorific Hi of 8.628 kWh _H i / liter. So that the vehicle has been used in the considered period so 83.340 kg x 13.393 kWh _Hi / kg = 1,116, 173 kWh _Hi of natural gas energy and 12.757 liter x 8,628 kWh _H i / liter = 110.067 kWh _H i of gasoline energy, total 1116.173 + 110.067 = 1,226,240 kWh _Hi . It is further known from the fuel database 31 that CNG is burdened on average with 249.5 gC0 ₂ / kWh _H i of life cycle emission and gasoline with 325.6 gC0 ₂ / kWh _H i. This results in a total LCA-THG emission of 1,116,173 kWh _H ix 249.5 gC0 ₂ / kWh _Hi = 278.485 gC0 ₂ from natural gas use and 110.067 kWh _Hi x 325.6 gC0 ₂ / kWh _Hi = 35.838 gC0 ₂ from gasoline use , In total, the life cycle emission amounts to 278,485 + 35,838 = 314,323 g C0 ₂ . Based on the distance of 1,594.9 km, the CO ₂ emissions are 197 gC0 ₂ / km. It goes without saying that in this way the stoichiometric C0 ₂ value can also be calculated, for which only the corresponding stoichiometric values have to be used instead of the LCA emission values. These calculations are overly inaccurate. In fact, the refueling position of embodiment 200 is much more complex.

The driver refuels id. not average fuels, but very different fuel subsets. In order to solve the technical problem of the inaccurate calculation of fuel consumption, energy consumption and GHG emissions described above, in addition to the technical idea of storing the GPS coordinates of the refueling locations and of the filling stations, the algorithm according to the invention is used. If reference is made below to this algorithm according to the invention, then this is to be understood as a clear procedure or procedure for solving the problem described at the outset or the inventive task. The algorithm consists of finitely many, well-defined individual steps, which are described in detail below. To carry out the action instruction (work instruction), the algorithm can be implemented in a computer program (software). The procedure disclosed here, which results from the described rules and is correspondingly systematic and logical, does not describe specific software, but the underlying idea and its technical implementation. Although the disclosed algorithm relies to a large extent on logical reasoning, its effectiveness still depends on the existence of a fuel database / file 31 and / or a gas station database / file 32. Without these (technical) databases or file (s), without the (technical) entries in these databases or files and without the (technical) update of these entries, the algorithm would not be able to provide correct result data to produce. The object to be patented, which in two respects consists only in part of the algorithm (the databases as a necessary complement to the algorithm and the algorithm including databases as a necessary part of the entire invention), does not solve a concrete technical problem by technical means in a non-obvious way and thereby makes a (technical) contribution to the further development of the state of the art. Accordingly, not only the concrete outward form of the algorithm should be placed under patent protection, but the technical idea and its implementation, which materializes in the underlying concept for solving the technical problem and in the disclosed procedure as well as in modifications of this procedure. The transfer of the inventive algorithm into a software "as such" (eg according to I EC 61131-3) is regarded as banal and trivial in this context. The creative or inventive activity is not in, but exclusively outside the program development. Accordingly, ownership of software programs should be justified only by copyright standards. Since copyright is subordinate to patent law, granted patent rights should be able to prevent copyright exploitation, ie it claims a protection for the abstract, which can prevent the unauthorized implementation of the concrete. From the GPS coordinates (not shown) of the refueling process (refueling location of the CNG vehicle 1) described by Refueling Records 1672/1673, the algorithm may be adjusted by matching these GPS coordinates with those stored in the refueling database 32 GPS coordinates of the individual gas stations determine that this CNG refueling took place at the gas station A. Also from the gas station database 32, the algorithm can determine by inquiry that this gas station A has delivered at the time of refueling the CNG vehicle 1 at its CNG columns pure CNG.

Further, the algorithm determines, by a corresponding query from the refueling process described by refueling records 1686/1687, that this second CNG refueling of the CNG vehicle 1 with CNG occurred at the gas station B. By querying the gas station database 32, the algorithm determines that this gas station B at the time of refueling on its CNG column has not given pure CNG a, but a mixture of 80% CNG and 20% bio methane.

From the third CNG refueling operation, described by records 1695/1696, the algorithm is notified from the GPS coordinates (not shown) that this third CNG refueling of the vehicle 1 occurred at the gas station C. From the gas station database 32, the algorithm determines that this gas station C has delivered pure bio-methane at the time of refueling the vehicle 1.

Finally, the algorithm determines by means of appropriate queries that the fourth CNG refueling of the CNG vehicle 1 described by the data records 1716/1717 took place at the gas station D and this gas station delivered pure methane ^ZeroEmisslon at the time of refueling of the vehicle 1.

In addition, the algorithm determines from the query of the last daily closing prior to the period to be examined or, in the case of working without daily closing, from the query of the last data record that occurred before the start of the period to be examined (in In this case, the record 1653) that at the beginning of the week there were still 9,500 kg of pure CNG in the tank 1 of the vehicle 1. Also important is the information that the driver of the vehicle 1 has not fueled the standard type of gasoline Super E5 in the fueling described by the records 1676/1677 at the gas station A, but Super E10. However, the amount of fuel still in tank 2 during fueling was still super E5.

The invention solves this complexity by the algorithm according to the invention, which can assume several different subforms and describes the basic procedure here only on the basis of one of many possible embodiments, in a step 01 supplements the data sets 102 supplied by the front end 7 by further data fields, namely, the additional data fields: 119 "fuel subspecies", 121 "leg", 122 "CNG amount", 123 "gasoline amount", 124 "amount of energy", 125 "life cycle emission quota", 126 "GHG emission amount", 127 "C0 _2- eq / km", 128 "petrol station".

In step 02, the algorithm calculates independently of the fuel main type used for each data set 102 from the data in the data field 117 (odometer reading) the distance covered in each case and stores the result in the additional data field "partial distance" 121 of the respective data records 102 the sub-route is determined by subtracting the odometer reading of the current record from the odometer reading of the next record, but there are also records that are not associated with trips, eg refueling records and daily records From data fields 117 (odometer reading) and 118 (main fuel type KHA ) of the Data records 102 may be read by the algorithm for each record as to whether a leg was ever traveled and, if so, what type of fuel is used.

Thus, in this embodiment, with the two main fuel types CNG and gasoline, the algorithm differentiates between segments covered with the fuel main CNG ("CNG" data) and segments associated with the main fuel gasoline ("gasoline "Records) was covered. There are of course other main fuel types and thus differentiations possible, for. B. only gasoline, only diesel, only CNG, only LNG, only LPG, only electric power, only hydrogen, electric power and gasoline, electric power and diesel, diesel and LNG, diesel and CNG etc. etc .. Also possible are drive systems that work with three or more fuels. The basic procedure remains the same.

With regard to the CNG covered legs, in the embodiment 200 shown here, which is just one of many, the "CNG" records 1655 (25.7 km), 1658 (27.2 km), 1661 (4th century) , 9 km), 1664 (5.0 km), 1669 (92.0 km), 1679 (378.0 km), 1684 (7.0 km), 1689 (27.0 km), 1692 (336.0 km), 1700 (75.0 km), 1704 (5.0 km), 1707 (5.0 km), 1711 (204.0 km), 1714 (22.0 km), 1719 (185.0 km) , 1723 (24.0 km) and 1726 (23.5 km) .The "gasoline" datasets are more numerous, as a rule but shorter, because the CNG vehicle is initially warmed up using gasoline after each start: 1654 (2.2 km), 1657 (0.80 km), 1660 (0.70 km), 1663 (0, 60 km), 1668 (2, 10 km), 1670 (36.00 km), 1674 (0.02 km), 1678 (0.20 km), 1680 (57.00 km), 1683 (1.60 km ), 1688 (0.15 km), 1691 (1.5 km), 1693 (34.00 km), 1697 (0.15 km), 1699 (0.30 km), 1703 (2.00 km), 1706 (1.8 km), 1710 (2.10 km), 1713 (1.70 km), 1718 (0.25 km), 1722 (1.90 km) and 1725 (1.50 km).

In a step 03, the algorithm first calculates CNG consumption for the main fuel type CNG from the data field 113 of the data records 102, for all CNG partial sections, and writes the calculation results into the additional data field 122 "CNG consumption per partial distance 121". the respective "CNG" datasets 102: 1655 (1.574 kg), 1658 (1.604 kg), 1661 (0.274 kg), 1664 (0.273 kg), 1669 (5.427 kg), 1679 (20.603 kg), 1684 (0.413 kg) , 1689 (1.524 kg), 1692 (19.167 kg), 1700 (4.816 kg), 1704 (0.295 kg), 1707 (0.295 kg), 1711 (12.033 kg), 1714 (1.298 kg), 1719 (10.912 kg), 1723 (1.416 kg), 1726 (1.386 kg).

In step 04-A, the algorithm initially determines for the fuel main type CNG from the filling level of the tank 1 (data field 113) and possibly also on the occasion (data field 109) the parts that were covered with exactly the CNG tank contents resulting from the last CNG refueling (not shown). The resulting in a refueling tank content is namely composed of the still in the tank befindlichem fuel residue and the added refueling amount. Since the next CNG refueling stop is first documented by refueling records 1672/1673, the algorithm concludes that all CNG legs with a record number <1672 have been completed with the tank contents resulting from the last previous refueling. First of all, CNG data sets 1655 (1.574 kg consumption), 1658 (1.604 kg consumption), 1661 (0.274 kg), 1664 (0.273 kg) and 1669 (5.427 kg) are concerned, with the CNG still contained in tank 1 Rest were left. In the exemplary embodiment of FIG. 25, the gaseous fuel still in tank 1 was used for all these CNG sections until refueling, which is described by data records 1672/1673, which was consumed to a remainder of 0.348 kg. From the data of the previous period, not shown here, the algorithm is known that this tank contents consisted of pure CNG.

In step 05-A, the algorithm determines from level 113 and additional data field 124 (amount of energy) of the last refueling record (not shown) by dividing the average lent specific energy content of the CNG tank 1 of the vehicle 1 CNG mixture. This is 13.393 kWh _H i per kg (not shown). Thus, the algorithm up to and including record 1671 can enter into the additional data field 124 "amount of energy" of the "CNG" data records among the data records 102, which energy inputs are entered in step 03 into the additional data field 122 "CNG consumption" of the respective CNG data records CNG masses correspond to: 1655: 21,074 kWh _Hi , 1658: 21,488 kWh _Hi , 1661: 3,675 kWh _Hi , 1664: 3,650 kWh _Hi , 1669: 72,680 kWh _Hi In addition, the algorithm calculates the CNG remaining in the CNG tank 1 contained energy amount (0.348 kg x 13.393 kWh _H i per kg = 4.667 kWh _H i) and stores them in the additional data field 124 "amount of energy" CNG refueling record 1672 from.

In step 06-A, the algorithm determines from data field 125 "life cycle emission quota" of the last refueling record (not shown), which life cycle emission quota resulted from the remaining CNG remainder and the last CNG refueling of vehicle 1. These were (not 249.5 gC0 ₂ / kWh _H i. Thus, the algorithm up to and including record 1671 can enter into the additional data field 125 "Life Cycle Emission Ratio" of the "CNG" records among the records 102, which lifecycle emission quotas previously entered into the respective "CNG". Records corresponding to energy inputs (namely in each case 249.5 gC0 ₂ / kWh _H i).

In step 07-A, the algorithm first multiplies for the CNG data sets among the data sets 1653 to 1671 (ie for 1655, 1658, 1661, 1664 and 1669) the input energy inputs 123 per segment 121 with the life cycle emission quotas 124 entered there, which is the LCA -THG emission levels 125 of the "CNG" datasets up to and including dataset 1671, namely for the CNG leg of dataset 1655: 5.258 gC0 ₂ , for the CNG leg of dataset 1658: 5.361 gC0 ₂ , for DS 1661: 917 gC0 ₂ , for DS 1664: 911 gC0 ₂ , for DS 1669: 18.134 gC0 _2. These calculation results are written by the algorithm in the additional data field 126 "GHG emission quantity" of these data sets.

In step 08-A, the algorithm divides, per CNG record 102 whose record number is <1672 (current refueling record), the LCA-THG emission amounts from the additional data field 126 "GHG emission amount" by the respective sub-link (additional data field 121 ), which gives the C0 ₂ value per kilometer, which is entered in the additional data field 127 "gC0 ₂ / km" of the respective data set: 1655: 205 gC0 ₂ -eq / km, 1658: 197 gC0 ₂ -eq / km, 1661: 187 gC0 ₂ -eq / km, 1664: 182 gC0 ₂ -eq / km, 1669: 197 gC0 ₂ -eq / km.

In step 09-A, the algorithm calculates the data for the 0.348 kg CNG residue located in CNG Tank 1 just prior to CNG refueling 1672/1673, which is listed in data field 113 "CNG Level Tank 1" of record 1672 The algorithm queries from the last refueling record (not shown here) which calorific value the CNG remainder still had in tank 1 before refueling 1672/1673, which is multiplied by the algorithm (13.393 kWh _hi / kg) It stores the result (4.667 kWh _H i) in the additional data field 124 "amount of energy" of the refueling record 1672 in the data field 113 of the refueling record 1672. In addition, the algorithm queries from the data field 125 of the last CNG refueling record (not shown), which life cycle emission quota has the CNG remainder of the last refueling record (not shown) (249.5 gC0 ₂ / kWh _H i, see step 06-A), multiply this one t with the value stored in additional data field 124 "amount of energy" of refueling record 1672 (4,661 kWh _H i; determined in step 05-A) and stores the result (1,164.29 gC0 ₂ ) in the additional data field 126 "GHG emission amount" of refueling record 1672. In a step 10-A, by subtracting the data field 113 of the refueling data record 1672 from the data field 113 of the refueling data record 1673, the algorithm determines the fuel quantity (21,152 kg CNG). The algorithm writes this information into the data field "refueling quantity CNG" of the refueling record "refueling 1672/1673", which is temporarily formed in the working memory.

From the refueling process described by data sets 1672/1673, the algorithm is informed in a step 11-A from the GPS coordinates (not shown) that the refueling was carried out at the gas station A (see the comments made above). , He writes this information in the additional data field 128 "petrol station" of the two refueling records 1672 and 1673.

In a step 12-A, the algorithm from the gas station database 32 determines that this gas station A has delivered the fuel subtype "Pure CNG" at the time of refueling 1672/1673 of the vehicle 1 (see above) the additional data field 119 "Fuel Subtype" of refueling record 1673.

In step 13-A, the algorithm queries from the fuel database 31 and / or the gas station database 32 as to which calorific value the "pure CNG" fuel subtype delivered by the gas station A on 03.04.2016 had. (13.393 kWh _H i / kg), the algorithm multiplies the quantity of gas (21,152 kg, determined in step 10-A) from the data field "refueling quantity CNG" of the refueling record "refueling 1672/1673", which is temporarily formed in the working memory _Hi ) he writes in the data field "Fueled amount of energy" of the temporarily formed in memory refueling record "refueling 1672/1673".

In step 14-A, the algorithm queries from the fuel database 31 and / or the gas station database 32 which life cycle emission quota the fuel sub-type "pure CNG" delivered by gas station A on April 3, 2016 has and writes this value (249 , 5 gC0 ₂ / kWh _H i) in the data field "life cycle emission quota" of the refueling record "refueling 1672/1673", which was temporarily formed in the working memory.

In step 15-A, the algorithm multiplies the value (283,283 kWh _H i, determined in step 13-A) of the refueling record "refueling 1672/1673" temporarily formed in the working memory, multiplied by that in the data field "Lifecycle mission quota" of the refueling record "refueling 1672/1673" temporarily stored in the memory (249.5 gC0 ₂ / kWh _Hi determined in step 14-A) and stores the result (70.679.11 gC0 ₂ ) in the data field " GHG emission quantity "of the refueling record" refueling 1672/1673 ", which was temporarily formed in the working memory.

In step 16-A, the algorithm adds the value stored in the additional data field 124 "amount of energy" of refueling record 1672 (4.667 kWh _H i, determined in step 5-A) to the refueling memory temporarily formed in the "energy amount" data field - Record "refueling 1672/1673" registered value (283,283 kWh _Hi , determined in step 13-A) and stores the result (287,950 kWh _H i) in the additional data field 124 "amount of energy" of the current refueling record 1673.

In step 17-A, the algorithm adds the value (1,164.29 gC0 ₂ ) determined in step 9-A and stored in additional data field 126 "GHG emission amount" of refueling record 1672 to that in the "GHG emission amount" field of FIG stored refueling record "Refueling 1672/1673" (70.679.11 gC0 ₂ , determined in step 15-A) and stores the result (71.843.40 gC0 ₂ ) in data field 126 "GHG emission amount" of refueling Record 1673 from. In step 18-A, the algorithm divides the value stored in additional data field 126 "GHG Emission Amount" of the current refueling record 1673 (71,843.40 gC0 ₂ determined in step 17-A) by refueling data field 124 "energy amount" Data set 1673 (287.950 kWh _Hi , determined in step 16-A) and stores the result (249.5 gC0 ₂ / kWh _Hi ) in the additional data field 125 "life cycle emission quota" of refueling record 1673.

In step 19-A, the algorithm deletes the no longer needed, temporarily stored in memory "refueling 1672/1673" and, in the event that there are more CNG records or CNG refills, goes to step 04 for a new pass B In the event that there are no more CNG records, the algorithm goes to step 20.

In step 04-B, the algorithm still determines for the fuel main type CNG from the fill level of the tank 1 (data field 113) and possibly also on the occasion (data field 109) the parts covered with the CNG tank contents, the resulted from the last CNG refueling 1672/1673. The resulting in a refueling tank content is namely composed of the still in the tank befindlichem fuel residue and the added refueling amount. Since after refueling 1672/1673 the next CNG refueling stop is documented by records 1686/1687, the algorithm concludes that all CNG legs with a record number> 1673 and <1686 have been completed with the tank contents resulting from refueling 1672 / 1673 resulted. Thus, the CNG data sets 1679 (consumption 20.603 kg) and 1684 (consumption 0.413 kg) are affected. In the exemplary embodiment of FIG. 25, the gas fuel in tank 1 was used for all these CNG sections up to the refueling, which is described by data records 1686/1687, which was consumed to a residual of 0.484 kg. From the last refueling 1672/1673 the algorithm is known that this tank contents consisted of pure CNG (the remainder of 0.348 kg and the refueling amount of 21.152 kg both consisted of pure CNG).

At step 05-B, the algorithm determines from level 113 and additional data field 124 (amount of energy) of the last refueling record 1673 by dividing the average specific energy content of the CNG mixture in the CNG tank 1 of the vehicle 1. As before, this is 13.393 kWh _H i per kg. Thus, the algorithm up to and including data record 1685 can enter into the additional data field 124 "amount of energy" of the "CNG" data records among the data records 102, which energy inputs are entered in step 03 into the additional data field 122 "CNG consumption" of the respective CNG data records CNG masses correspond to: 1679: 275.94 kWh _H i and 1684: 5.53 kWh _H i- In addition, the algorithm calculates the amount of energy contained in the current CNG remnant of CNG tank 1 (0.484 kg x 13.393 kWh _Hi per kg = 6.480 kWh _Hi ) and stores them in the additional data field 124 "amount of energy" of the CNG refueling record 1686.

In step 06-B, the algorithm retrieves from the data field 125 "life cycle emission quota" of the last refueling record 1673 which (new) average life cycle emission quota resulted from the remaining CNG remainder and the last CNG refueling of the vehicle 1. That were 249.5 gC0 ₂ / kWh _H i (determined in step 18-A), so that the algorithm up to and including record 1685 can be included in the additional data field 125 "life cycle emission quota" of the "CNG" records among the records 102 (in run B, ie in datasets 1679 and 1684) indicate which lifecycle emission quotas correspond to the energy inputs previously entered into the respective "CNG" datasets (namely 249.5 gC0 ₂ / kWh _H i each).

In step 07-B, the CNG dataset algorithm among datasets 1674-1685 (ie, 1679 and 1684) multiplies the input energy inputs 123 per leg 121 with the life cycle emission quotas 124 entered therein, which gives the LCA-THG emission levels 125 " CNG "datasets up to and including dataset 1685, namely for the CNG leg of the data record 1679: 68.847 gC0 ₂ and for the CNG subset of the data set 1684: 1.380 gC0 ₂ . The algorithm writes these calculation results in the additional data field 126 "GHG emission quantity" of these data records.

In step 08-B, the algorithm divides the LCA-THG emission quantities per CNG record 102 whose record number is> 1673 (last refueling record) and <1686 (current refueling record) (ie for 1679 and 1684) additional data field 126 "GHG emission quantity" through the respective sub-route (additional data field 121), which yields the C0 ₂ value per kilometer, which is entered in the additional data field 127 "gC0 ₂ / km" of the respective data set: 1679 : 182 gC0 ₂ -eq / km and 1684: 197 gC0 ₂ -eq / km.

In step 09-B, the algorithm calculates the data for 0.844 kg CNG est immediately before CNG refueling 1686/1687 in CNG tank 1, which is in data field 113 "CNG fill tank 1" of refueling record 1686 The algorithm queries from the last refueling record (in this case refueling record 1673), the calorific value of the CNG residue still remaining in tank 1 before refueling 1686/1687, this value (13.393 kWh _H i / kg), the algorithm multiplies by the residual amount of CNG (0.484 kg) listed in data field 113 of refueling record 1686. It stores the result (6.480 kWh _H i) in fueling record additional data field 124 "Fuel Amount" 1686 In addition, the algorithm retrieves from the data field 125 of the last CNG refueling record (in this case from the refueling record 1673) which life cycle emission quota contained the CNG remainder (249.5 gC0 ₂ / kWh _H i, see step 06 -B), mu ltiplies this value with the value stored in the additional data field 124 "amount of energy" of the data set 1686 (6.480 kWh _H i; determined in step 05-B) and stores the result (1.616.6 gC0 ₂ ) in the additional data field 126 "GHG emission amount" of refueling record 1686.

In a step 10-B, by subtracting the data field 113 of the refueling record 1686 from the data field 113 of the refueling record 1687, the algorithm determines the fuel quantity (21,400 kg CNG). This information is written by the algorithm into the data field "CNG refueling quantity" of the refueling record "Refueling 1686/1687", which is formed temporarily in the working memory.

From the refueling process described by data sets 1686/1687, the algorithm is informed in a step 11-B from the GPS coordinates (not shown) that the refueling was carried out at the gas station B (see the comments made above). , He writes this information in the additional data field 128 "gas station" of the two data sets 1686 and 1687.

In a step 12-B, the algorithm from the gas station database 32 determines that the gas station B delivered the fuel subtype "mixture of 80% CNG and 20% bio methane" at the time of refueling 1686/1687 of the vehicle 1. This information the algorithm writes into the additional data field 119 "Fuel Subtype" of refueling record 1687.

In step 13-B, the algorithm queries from the fuel database 31 and / or the gas station database 32 as to which calorific value the fuel substation delivered by the filling station B on 04.04.2016 "mixture of 80% CNG and 20% bio methane" This value (13.393 kWh _hi / kg) is multiplied by the algorithm with the gas quantity (20.916 kg, determined in step 10-B) from the data field "Refueling quantity CNG" of the fueling refueling record "Refueling 1686/1687". The result (280.131 kWh _Hi ) he writes in the data field "amount of energy" of the temporarily formed in memory record "refueling 1686/1687". In step 14-B, the algorithm queries from the fuel database 31 and / or the gas station database 32 which life cycle emission quota the fuel subtype "fuel mixture 80% CNG and 20% bio methane" submitted by the gas station B on 04.04.2016 had and writes this value (214.5 gC0 ₂ / kWh _H i) into the data field "life cycle emission quota" of the data set "Refueling 1686/1687", which was temporarily stored in the main memory.

In step 15-B, the algorithm multiplies the value entered in the data field "amount of energy" of the refueling record "refueling 1686/1687" formed temporarily in the working memory (280.131 kWh _H i, determined in step 13-B), multiplied by that in the data field "Life cycle emission quota" of the refueling record "refueling 1686/1687" temporarily stored in the memory (214.5 gC0 ₂ / kWh _Hi , determined in step 14-B) and stores the result (60.082,43 gC0 ₂ ) in the data field " GHG emission quantity "of the refueling record" refueling 1686/1687 ", which was temporarily formed in the working memory.

In step 16-B, the algorithm adds the value stored in the additional data field 124 "amount of energy" of refueling record 1686 (6.480 kWh _H i, determined in step 5-B) to the refueling memory temporarily formed in the "energy amount" data field - Record "refueling 1686/1687" registered value (280.131 kWh _Hi , determined in step 13-B) and stores the result (286.610 kWh _H i) in the additional data field 124 "amount of energy" of the current refueling record 1687.

In step 17-B, the algorithm adds the value (1.616.6 gC0 ₂ ) determined in step 9-B and stored in additional data field 126 "GHG emission amount" of refueling record 1686 to that in the "GHG emission amount" field of FIG stored refueling record "refueling 1686/1687" stored in memory (60,082.43 gC0 ₂ , determined in step 15-B) and stores the result (61,699.07 gC0 ₂ ) in data field 126 "GHG emission amount" of refueling Record 1687 from.

In step 18-B, the algorithm divides the value stored in additional data field 126 "GHG emission amount" of the current refueling record 1687 (61,699.07 gC0 ₂ , determined in step 17-B) by the amount of "energy" in the additional data field 124 Refueling record 1687 (286.610 kWh _H i, determined in step 16-B) and stores the result (215.3 gC0 ₂ / kWh _H i) in the additional data field 125 "life cycle emission quota" of refueling record 1687.

In step 19-B, the algorithm clears the no longer needed, temporarily stored in memory "refueling 1686/1687" and, in the event that there are more CNG records or CNG refills, goes to step 04 for a new pass C In the event that there are no more CNG records, the algorithm goes to step 20.

In step 04-C, the algorithm still determines for the fuel main type CNG from the fill level of the tank 1 (data field 113) and possibly also on the occasion (data field 109) the parts covered with the CNG tank contents resulting from the last CNG refueling 1686/1687. The resulting in a refueling tank content is namely composed of the still in the tank befindlichem fuel residue and the added refueling amount. Since after refueling 1686/1687 the next CNG refueling stop is documented by the records 1695/1696, the algorithm concludes that all CNG legs with a record number> 1687 and <1695 were completed with the tank contents resulting from refueling 1686 / 1687 resulted. Thus, CNG data sets 1689 (consumption 1,524 kg) and 1692 (consumption 19,167 kg) are affected. In the embodiment of FIG 25 thus came for these CNG sections up to the Refueling, which is described by the records 1695/1696, the gas fuel in the tank 1 is used, which was consumed to a remainder of 0.709 kg. From the last refueling 1686/1687 the algorithm is known to consist of CNG and BioMethane (the remainder of 0.484 kg was pure CNG and the refueling amount of 20.916 kg was 80% CNG and 20% BioMethane).

In step 05-C, the algorithm of the level 113 and the additional data field 124 (amount of energy) of the last refueling record 1687, by division, determines the average specific energy content of the CNG mixture in the CNG tank 1 of the vehicle 1. As before, this is 13.393 kWh _H i per kg. Thus, the algorithm up to and including record 1694 can enter into the additional data field 124 "amount of energy" of the "CNG" data records under the data records 102, which energy inputs are entered in step 03 into the additional data field 122 "CNG consumption" of the respective CNG data records CNG masses correspond to: 1689: Consumption 20,412 kWh _Hi and 1692: Consumption 256,704 kWh _Hi Furthermore, the algorithm calculates the amount of energy contained in the current CNG remnant of CNG tank 1 (0,709 kg x 13,393 kWh _H i per kg = 9,494 kWh _H) i) and stores them in the additional data field 124 "amount of energy" of the CNG refueling record 1695.

In step 06-C, the algorithm retrieves from the data field 125 "life cycle emission quota" of the last refueling record 1687 which (new) average life cycle emission quota resulted from the remaining CNG remainder and the last CNG refueling of the vehicle 1. That were 215.3 gC0 ₂ / kWh _H i (determined in step 18-B), so that the algorithm up to and including record 1694 can be included in the additional data field 125 "life cycle emission quota" of the "CNG" records among the records 102 (in run e, in records 1689 and 1692) indicate which life cycle emission rates correspond to the energy inputs previously entered in the respective "CNG" datasets (namely 215.3 gC0 ₂ / kWh _H i each).

In step 07-C, the CNG dataset algorithm under datasets 1688 to 1694 (ie, 1689 and 1692) multiplies the input energy inputs 123 per leg 121 by the life cycle emission quotas 124 entered therein, which gives the LCA-THG emission levels 125 of " CNG "datasets up to and including dataset 1694, namely for the CNG leg of dataset 1689: 4.394 gC0 ₂ and for the CNG leg of dataset 1692: 55.261 gC0 _2. These computation results are written by the algorithm into the additional data field 126" THG ". Emission quantity "of these data sets.

In step 08-C, the algorithm divides the LCA-THG emission amounts per CNG record 102 whose record number is> 1687 (last refueling record) and <1695 (current refueling record) (ie, for 1689 and 1692) additional data field 126 "GHG emission quantity" through the respective sub-route (additional data field 121), which yields the C0 ₂ value per kilometer, which the algorithm enters in the additional data field 127 "gC0 ₂ / km" of the respective data record: 1689 : 163 gC0 ₂ -eq / km and 1692: 164 gC0 ₂ -eq / km.

In step 09-C, the algorithm calculates the data for the CNG residue of 0.709 kg located in CNG tank 1 immediately prior to CNG refueling 1695/1696, which is in data field 113 CNG level tank 1 of refueling record 1695 The algorithm queries from the last refueling record (in this case refueling record 1687) the calorific value of the CNG remainder remaining in tank 1 before refueling 1695/1696 This value (13.393 kWh _H i / kg), the algorithm multiplies the CNG remainder (0.709 kg) listed in data field 113 of refueling record 1695. It stores the result (9.494 kWh _H i) in additional data field 124 "Amount of energy" of refueling record 1695 In addition, the algorithm asks from the data field 125 of the last CNG refueling record (in this case from the refueling record 1687), which life cycle emission quota had the CNG est amount (215.3 gC0 ₂ / kWh _H i, see step 06-C) , multiplies this value by the value stored in additional data field 124 "energy amount" of data set 1695 (9.494 kWh _H i, determined in step 05-C) and stores the result (2.043.83 gC0 ₂ ) in additional data field 126 "GHG emission amount from refueling record 1695.

In a step 10-C, by subtracting the data field 113 of the refueling record 1695 from the data field 113 of the refueling record 1696, the algorithm determines the fuel quantity (20.441 kg CNG). The algorithm writes this information into the data field "refueling quantity CNG" of the refueling record "refueling 1695/1696", which is formed temporarily in the working memory.

From the refueling process described by data sets 1695/1696, the algorithm is informed in a step 11-C from the GPS coordinates (not shown) that the refueling was carried out at the gas station C (see the statements made above). , He writes this information in the additional data field 128 "gas station" of the two data sets 1695 and 1695.

In a step 12-C, the algorithm from the gas station database 32 determines that the gas station C delivered the fuel subtype "100% bio methane" at the time of refueling 1695/1696 of the vehicle 1. This information is written by the algorithm in FIG the additional data field 119 "Fuel Subtype" of refueling record 1696.

In step 13-C, the algorithm retrieves from the fuel database 31 and / or the gas station database 32 what calorific value the fuel sub-type "100% bio-methane" delivered by the gas station C on April 4, 2016 had (13,393 kWh _hi / kg), the algorithm multiplies the gas quantity (20.441 kg, determined in step 10-C) from the data field "refueling quantity CNG" of the refueling record "refueling 1695/1696", which is formed temporarily in the working memory. 273.768 kWh _H i) he writes in the data field "amount of energy" of the temporarily formed in the working memory record "refueling 1695/1696".

In step 14-C, the algorithm queries from the fuel database 31 and / or the gas station database 32 which life cycle emission quota the fuel sub-type "100% bio-methane" issued by the gas station C on 04.04.2016 had and writes this value ( 74.4 gC0 ₂ / kWh _Hi ) into the data field "life cycle emission quota" of the data set "Refueling 1695/1696", which is temporarily stored in the main memory.

In step 15-C, the algorithm multiplies the value (273,768 kWh _H i determined in step 13-C) of the refueling record "refueling 1695/1696" formed temporarily in the memory in the data field "energy amount" by multiplying it by that in the data field "Life-cycle emission quota" of the refueling record "refueling 1686/1687" temporarily stored in memory (74.4 gC0 ₂ / kWh _Hi , determined in step 14-C) and stores the result (20.368,32 gC0 ₂ ) in the data field " GHG emission quantity "of the refueling record" refueling 1695/1696 ", which was temporarily formed in the working memory.

In step 16-C, the algorithm adds the value (9.494 kWh _H i, determined in step 5-C) stored in additional energy input field 124 of refueling record 1695 to refueling temporarily stored in memory in the data field "energy amount" - Record "refueling 1695/1696" registered value (273.768 kWh _Hi , determined in step 13-C) and stores the result (283.262 kWh _H i) in the additional data field 124 "amount of energy" of the current refueling record 1696. In step 17-C, the algorithm adds the value (2,043.83 gC0 ₂ ) determined in step 9-C and stored in additional data field 126 "GHG emission amount" of refueling record 1695 to that in the "GHG emission amount" field of FIG stored refueling record "refueling 1695/1696" stored in memory (20,368.32 gC0 ₂ , determined in step 15-C) and stores the result (22,412.15 gC0 ₂ ) in data field 126 "GHG emission quantity" of refueling Record 1696 from.

In step 18-C, the algorithm divides the value (22,412.15 gC0 ₂ , determined in step 17-C) stored in additional data field 126 "GHG Emission Amount" of the current refueling record 1696 by the amount of "energy" in the additional data field 124 Refueling record 1696 stored value (283.262 kWh _H i, determined in step 16-C) and stores the result (79.1 gC0 ₂ / kWh _H i) in the additional data field 125 "life cycle emission quota" of refueling record 1696.

In step 19-C, the algorithm clears the no longer needed, temporary in-memory record "refueling 1695/1696" and, in the event that there are more CNG records or CNG refills, goes to step 04 for a new pass D In the event that there are no more CNG records, the algorithm goes to step 20.

In step 04-D, the algorithm still determines for the main fuel CNG from the level of the tank 1 (data field 113) and possibly also on the occasion (data field 109), the parts that were covered with the CNG tank contents, the resulting from the last CNG refueling 1695/1696. The resulting in a refueling tank content is namely composed of the still in the tank befindlichem fuel residue and the added refueling amount. Since after refueling 1695/1696 the next CNG refueling stop is documented by the records 1716/1717, the algorithm concludes that all CNG legs with a record number> 1696 and <1716 were completed with the tank contents resulting from refueling 1695 / 1696 resulted. Thus, the CNG data sets 1700 (4,816 kg consumption), 1704 (0,295 kg), 1707 (0,295 kg), 1711 (12,033 kg) and 1714 (consumption 1,298 kg) are affected. In the exemplary embodiment of FIG. 25, the gas fuel contained in the tank 1 was used for these CNG sections up to the refueling, which is described by the data records 1716/1717, which was consumed except for a remainder of 2.413 kg. From the last refueling 1695/1696 the algorithm is known to consist of CNG and BioMethane (the remainder of 0.484 kg consisted of a CNG / BioMethan mixture and the refueling amount of 20.916 kg was 100% BioMethane).

In step 05-D, the algorithm from the level 113 and the additional data field 124 (amount of energy) of the last refueling record 1696 divides the average specific energy content of the CNG mixture in the CNG tank 1 of the vehicle 1 by dividing. As before, this is 13.393 kWh _H i per kg. Thus, the algorithm up to and including data record 1715 can enter into the additional data field 124 "amount of energy" of the "CNG" data records among the data records 102, which energy inputs are entered in step 03 into the additional data field 122 "CNG consumption" of the respective CNG data records CNG masses correspond to: 1700 (consumption 64,500 kWh _Hi ), 1704 (3,950 kWh _Hi ), 1707 (3,950 kWh _Hi ), 1711 (161,160 kWh _Hi ) and 1714 (consumption 17,380 kWh _H i) CNG residue of the CNG tank 1 contained energy amount (2.413 kg x 13.393 kWh _H i per kg = 32.322 kWh _H i) and stores them in the additional data field 124 "amount of energy" CNG refueling record 1716 from.

In step 06-D, the algorithm retrieves from the data field 125 "life cycle emission quota" of the last refueling record 1696 which (new) average life cycle emission quota resulted from the remaining CNG remainder and the last CNG refueling of the vehicle 1. This was 79.1 gC0 ₂ / kWh _H i (determined in step 18-C). Thus, the algorithm up to and including data record 1715 can enter into the additional data field 125 "Life Cycle Emission Ratio" of the "CNG" data sets among the data records 102 (in the data flow D thus in the data records 1700, 1704, 1707, 1711 and 1714), which life cycle emission quotas the energy inputs previously entered into the respective "CNG" data records (namely 79.1 gC0 ₂ / kWh _H i each).

In step 07-D, the algorithm for the CNG data records among the data records 1697 to 1715 (ie for 1700, 1704, 1707, 1711 and 1714) multiplies the input energy inputs 123 per segment 121 by the life cycle emission quotas 124 entered there, which the LCA GHG emissions 125 of the "CNG" datasets up to and including dataset 1715, namely for the CNG leg of the dataset 1700: 5.103 gC0 ₂ , 1704: 313 gC0 ₂ , 1707: 313 gC0 ₂ , 1711: 12.751 gC0 ₂ and for the CNG leg of record 1714: 1.375 gC0 _2. These computation results are written by the algorithm to the additional data field 126 "GHG Emission Amount" of records 1700, 1704, 1707, 1711 and 1714.

In step 08-D, the algorithm divides the LCA per CNG record 102 whose record number is> 1696 (last refueling record) and <1716 (current refueling record) (ie, for 1700, 1704, 1707, 1711, and 1714) THG emission quantities from the additional data field 126 "GHG emission quantity" through the respective sub-route (additional data field 121), which gives the C0 ₂ value per kilometer, the algorithm carries this value into the additional data field 127 "gC0 ₂ / km" of the respective data set: 1700: 68 gC0 ₂ -eq / km, 1704: 63 gC0 ₂ -eq / km, 1707: 63 gC0 ₂ -eq / km, 1711: 63 gC0 ₂ -eq / km and 1714: 63 gC0 ₂ eq / km.

In step 09-D, the algorithm calculates the data for the CNG est of 2.413 kg located in CNG tank 1 immediately prior to CNG refueling 1716/1717, which is in refueling record 1716 "CNG level tank 1" data field 113 The algorithm queries from the last refueling record (in this case refueling record 1696) the calorific value of the remaining CNG residue in tank 1 prior to refueling 1716/1717, this value (13.393 kWh _H i / kg), the algorithm multiplies by the remaining CNG amount (2.413 kg) listed in data field 113 of refueling record 1716. It stores the result (32.322 kWh _H i) in additional data field 124 "Amount of energy" of refueling record 1716 In addition, the algorithm retrieves from the data field 125 of the last CNG refueling record (in this case from the refueling record 1696) which life cycle emission quota contained the CNG remainder (79.1 gC0 ₂ / kWh _H i, see step 06 -D), mu ltiplicts this value with the value stored in the additional data field 124 "amount of energy" of the data set 1716 (32.322 kWh _H i; determined in step 05-D) and stores the result ( ₂ 557.37 gC0 ₂ ) in the additional data field 126 "GHG emission amount" of the refueling data record 1716.

In a step 10-D, by subtracting the data field 113 of the refueling record 1716 from the data field 113 of the refueling record 1717, the algorithm determines the fuel quantity (17.447 kg CNG). The algorithm writes this information into the data field "refueling quantity CNG" of the refueling record "refueling 1716/1717", which is formed temporarily in the working memory.

From the refueling process described by records 1716/1717, the algorithm is informed in a step 11-D from the GPS coordinates (not shown) that the refueling was carried out at the gas station D (see the comments made above). , He writes this information in the additional data field 128 "gas station" of the two data sets 1716 and 1717. In a step 12-D, the algorithm determines from the filling station database 32, that the filling station D at the time of refueling 1716/1717 of the vehicle 1, the fuel subspecies "100% Methanakg _e g _e e _s t _na This information writes the algorithm into the additional data field 119 "fuel subspecies" of refueling record 1717.

In step 13-D, the algorithm retrieves from the fuel database 31 and / or the gas station database 32 what calorific value the fuel subtype "100% methane ^ZeroEmission " emitted by the gas station D on 06.04.2016 had. 13.393 kWh _hi / kg), the algorithm multiplies the quantity of gas (17.447 kg, determined in step 10-D) from the data field "refueling quantity CNG" of the fueling refueling record "refueling 1716/1717" (233,663 kWh _H i) he writes in the data field "amount of energy" of the temporarily formed in the working memory record "refueling 1716/1717".

In step 14-D, the algorithm queries from the fuel database 31 and / or the gas station database 32 as to which life cycle ^{emission quota the fuel substation} "100% methane ^ZeroEmission " emitted by the gas station D on April ^{6, 2016 has} and writes this value (0,0 gC0 ₂ / kWh _H i) into the data field "life cycle emission quota" of the data set "Refueling 1716/1717", which is temporarily stored in the working memory.

In step 15-D, the algorithm multiplies the value (233,663 kWh _H i, determined in step 13-D) entered in the "fuel quantity" data field of the refueling record "refueling 1716/1717", which is temporarily formed in the main memory, multiplied by that in the data field "Lifecycle mission quota" of the refueling record "Refueling 1716/1717" temporarily stored in memory (0.0 gC0 ₂ / kWh _Hi determined in step 14-D) and stores the result (0.0 gC0 ₂ ) in the data field " GHG emission quantity "of the refueling record" Refueling 1716/1717 ", which was temporarily formed in the working memory.

In step 16-D, the algorithm adds the value (32.322 kWh _H i, determined in step 5-D) stored in additional energy input field 124 of refueling record 1716 to refueling temporarily stored in memory in the energy amount data field - Record "refueling 1716/1717" registered value (233,663 kWh _Hi , determined in step 13-D) and stores the result (265.985 kWh _H i) in the additional data field 124 "amount of energy" of the current refueling record 1717.

In step 17-D, the algorithm adds the value (2,557.37 gC0 ₂ ) determined in step 9-D and stored in additional data field 126 "GHG emission amount" of refueling record 1716 to that in the "GHG emission amount" field of FIG stored refueling record "refueling 1716/1717" (0.0 gC0 ₂ , determined in step 15-D) and stores the result ( ₂ 557.37 gC0 ₂ ) in data field 126 "GHG emission quantity" of refueling Record 1717 from.

In step 18-D, the algorithm divides the value stored in additional data field 126 "GHG Emission Amount" of the current refueling record 1717 ( ₂ 557.37 gC0 ₂ , determined in step 17-D) by the amount of "Energy Amount" of the additional data field 124 in FIG Refueling record 1717 (265.985 kWh _H i, determined in step 16-D) and stores the result (9.6 gC0 ₂ / kWh _H i) in the additional data field 125 "life cycle emission quota" of refueling record 1717.

In step 19-D, the algorithm deletes the no longer needed, temporarily stored in the working memory record "refueling 1716/1717" and goes in the event that there are more CNG Records or CNG refueling returns to step 04 for a new pass E. In the event that there are no more CNG records, the algorithm goes to step 20.

In step 04-E, the algorithm still determines for the fuel main type CNG from the fill level of the tank 1 (data field 113) and possibly also on the occasion (data field 109) the parts that were covered with the CNG tank contents resulting from the last CNG refueling 1716/1717. The resulting in a refueling tank content is namely composed of the still in the tank befindlichem fuel residue and the added refueling amount. Since after refueling 1716/1717 the next CNG refueling stop has not yet been documented, the algorithm concludes that all CNG sections with a data record number> 1717 were covered with the tank contents resulting from refueling 1716/1717. So it affects the CNG data sets 1719 (consumption 10.912 kg), 1723 (1.416 kg) and 1726 (1.386 kg). In the exemplary embodiment of FIG. 25, for this CNG partial sections after the last CNG refueling, the gas fuel in the tank 1 was used, which was consumed except for a remainder of 6.146 kg. From the last refueling 1716/1717 the algorithm is known that the last tank contents consisted of a mixture of CNG, bio methane and methane ^{zero emission} .

In step 05-E, the algorithm from the level 113 and the additional data field 124 (amount of energy) of the last refueling data set 1717 determines by division the average specific energy content of the CNG mixture in the CNG tank 1 of the vehicle 1. As before, this is 13.393 kWh _H i per kg. Thus, the algorithm up to and including data record 1728 can enter into the additional data field 124 "energy quantity" of the "CNG" data records under the data records 102, which energy inputs are entered in step 03 into the additional data field 122 "CNG consumption" of the respective CNG data records CNG masses correspond to: 1719 (consumption 146.150 kWh _Hi ), 1723 (18.960 kWh _Hi ), and 1726 (18.565 kWh _Hi ) Since there is no new refueling record, the algorithm calculates no current CNG remainder.

In step 06-E, the algorithm retrieves from the data field 125 "life cycle emission quota" of the last refueling record 1717 which (new) average life cycle emission quota resulted from the remaining CNG remainder and the last CNG refueling of the vehicle 1. That were 9.6 gC0 ₂ / kWh _H i (determined in step 18-D), so that the algorithm up to and including record 1728 can be included in the additional data field 125 "Life Cycle Emission Ratio" of the "CNG records" among the records 102 (ie, in Run E) Records 1719, 1723, and 1726) indicate which life cycle emission rates correspond to the energy inputs previously entered into the respective "CNG" data sets (namely, 9.6 gC0 ₂ / kWh _H i, respectively).

In step 07-E, the algorithm for the CNG data sets among the data sets 1718 to 1728 (ie for 1719, 1723 and 1726) multiplies the input energy inputs 123 per segment 121 by the life cycle emission quotas 124 entered therein, which gives the LCA-THG emission quantities 125 for the CNG subset of data set 1719: 1.405 gC0 ₂ , 1723: 182 gC0 _2, and for the CNG subset of the data set 1726: 178 gC0 _2. The computation results are written by the algorithm into the additional data field 126 "GHG emission amount" of the data sets 1719, 1723 and 1726.

In step 08-E, the algorithm divides, per CNG record 102 whose record number is> 1717 (last refueling record) (ie for 1719, 1723 and 1726), the LCA-THG emission amounts from the additional data field 126 "GHG emission amount through the respective segment (additional data field 121), which gives the C0 ₂ value per kilometer, which is entered in the additional data field 127 "gC0 ₂ / km" of the respective data set: 1719: 8 gC0 ₂ -eq / km, 1723: 8 gC0 ₂ -eq / km, and 1726: 8 gC0 ₂ -eq / km. In step 09-E, the algorithm does not calculate data for the CNG est in CNG tank 1 because there is no next CNG refueling record.

In a step 10-E, the algorithm detects nothing because there are no more CNG refueling records.

In step 11-E, the algorithm calculates nothing because there are no more CNG refueling records.

In step 12-E, the algorithm calculates nothing because there are no more CNG refueling records.

In step 13-E, the algorithm calculates nothing because there are no more CNG refueling records.

In step 14-E, the algorithm calculates nothing because there are no more CNG refueling records.

In step 15-E, the algorithm calculates nothing because there are no more CNG refueling records.

In step 16-E, the algorithm calculates nothing because there are no more CNG refueling records.

In step 17-E, the algorithm calculates nothing because there are no more CNG refueling records.

In step 18-E, the algorithm calculates nothing because there are no more CNG refueling records.

In step 19-E, the algorithm does not clear anything since it has not formed a temporary fueling record "refueling XYZ." Since there are no further unprocessed CNG records after run E, the algorithm moves to step 20.

The 4 CNG refueling operations listed in the raw data list 200 have defined a total of 5 data areas with partial routes covered by the main fuel CNG ("CNG" data sets), namely data areas A (records 1653-1671), B (records 1674-1685), C (records 1688-1694), D (records 1697-1715) and E (records 1718-1728). As the technical data (energy content or calorific value, GHG emission quota, GHG emissions) of the content of the CNG tank 1 with each refueling, it is always necessary to first evaluate the refueling record before the subsequent data sets describing the CNG sections can be supplemented with data on energy input and GHG emissions as previously described (ie first for a refueling record and then for the subsequent data area to before the next refueling record, etc.) or alternatively for all refueling records u nd then for all "CNG" datasets, with the algorithm for supplementing the CNG datasets accessing the respective refueling and their datasets. In order to avoid repetition, this alternative approach, which incidentally can also be used to supplement "gasoline" data sets, is not presented here and is nevertheless intended to be within the scope of protection, regardless of which main fuel type or combinations of fuel Likewise, it is intended to be within the scope of the invention if the steps of data set completion and / or data computation are performed in any order other than that described in detail herein. The algorithm according to the invention has calculated in step 02 for all "CNG" partial sections of the raw data extract 200 the respective partial route length 121, in step 03 the respective route-specific fuel consumption, in step 05 the respective route-specific energy input 124, in step 07 respective route-specific GHG emission quantity 126 and the respective route-specific GHG emission quota 127 in gC0 ₂ -eq / km in step 08. Except for the GHG emission quota 127, the algorithm adds this section-specific data to CNG in step 20. For the "CNG" datasets 1655, 1658, 1661, 1664, 1669, 1679, 1684, 1689, 1692, 1700, 1704, 1707, 1711, 1714, 1719, 1723, 1726, the addition of the partial line Lengths 121 a CNG total distance of 1,446.3 km. The addition of the individual CNG consumption quantities 122 measured in kg gives a total consumption of 83.310 kg of gas of different qualities. The addition of the individual energy input quantities 124 results in a total input of 1,115,768 kWh _H i and the addition of the individual GHG emission amounts 126 a total emission of 182,083 gC0 ₂ equivalents. These totals are calculated according to causation, ie they are not based on average considerations or average values, but take into account the different technical data of the various fuel sub-types used 119.

In step 21, the algorithm calculates the specific quota values for the main fuel CNG, namely the route-specific energy input, which is 1,115.768 kWh _Hi / 1.446.3 km _CN G = 0.771 kWh _H i / km _C NG, the energy specific GHG emission quota, which amounts to 182,083 gC0 ₂ / 1,115,768 kWh _H i = 163,2 gC0 ₂ / kWh _H i, and the route-specific GHG emission quota, which is 182,083 gC0 ₂ /1,446.3 km _CN G = 125.9 gC0 ₂ / km calculated.

Step 22 corresponds to step 03, but now the algorithm does not compute the fuel main CNG data sets, but the second main fuel data sets, which in the embodiment shown here, is the main fuel gasoline (eg, it could also be the fuel - be the main type of diesel or another type of fuel, with electricity being considered the main fuel type). From the data field 113 of the data sets 102, the algorithm now determines the gasoline consumption as volume for all gasoline partial sections and writes the calculation results into the additional data field 123 "Gasoline consumption per partial section 121" of the respective "gasoline" data records 102: 1654 (0.218 liters), 1657 (0.071 liters), 1660 (0.065 liters), 1663 (0.058 liters), 1668 (0.185 liters), 1670 (3.060 liters), 1674 (0.002 liters), 1678 (0.026 liters), 1680 ( 4,845 liters), 1683 (0.152 liters), 1688 (0.020 liters), 1691 (0.140 liters), 1693 (2,890 liters), 1697 (0.020 liters), 1699 (0.028 liters), 1703 (0.170 liters), 1706 (0.162 liters ), 1710 (0.200 liters), 1713 (0.134 liters), 1718 (0.024 liters), 1722 (0.167 liters) and 1725 (0.122 liters).

In step 23-A, which corresponds to step 04-A, determines the algorithm for the fuel main type gasoline from the level of the tank 2 (data field 114) and possibly also on the occasion (data field 109), the parts with exactly the gasoline tank contents that resulted from the last gasoline refueling (not shown). The resulting in a refueling tank content is namely composed of the still in the tank befindlichem fuel residue and the added refueling amount. Since after the last gasoline refueling (not shown) the next gasoline refueling stop is documented by records 1676/1677, the algorithm concludes that all gasoline stretches with a record number> 1652 and <1676 have been completed with the tank contents being from the last gasoline refueling (not shown). Thus, first of all, the gasoline data sets 1654 (consumption 0.218 liters), 1657 (consumption 0.071 liters), 1660 (0.065 liters), 1663 (0.058 liters), 1668 (0.185 liters), 1670 (3.060 liters) and 1674 (0.002 liters In the exemplary embodiment of FIG. 25, for the gasoline sections up to the refueling, which is described by the data records 1676/1677, the gasoline engine located in the tank 2 came into being. Substance used, which was consumed except for a remainder of 7,831 I. From the last, prior to 01.04.2016 lying gasoline refueling (not shown), the algorithm is known that the tank contents of the tank 2 consisted of Super E5.

In step 24-A, corresponding to step 05-A, the algorithm determines the level 114 and the additional data field 124 (amount of energy) of the last refueling record (not shown) by dividing the average specific energy content of the gasoline tank 2 of the vehicle 1 located gasoline mixture. This is (not shown) 8.628 kWh _H i per liter Super E5. Thus, the algorithm up to and including data set 1675 can enter into the additional data field 124 "amount of energy" of the "gasoline" data sets among the data sets 102, which energy inputs the in step 22-A in the additional data field 123 "gasoline consumption" of the respective gasoline Recorded gas volumes correspond to: 1654 (consumption 1,879 kWh _H i), 1657 (consumption 0.614 kWh _Hi ), 1660 (0.562 kWh _Hi ), 1663 (0.502 kWh _Hi ), 1668 (1.594 kWh _Hi ), 1670 (26.402 kWh _H i), 1674 (0.019 kWh _H i) In addition, the algorithm calculates the amount of energy contained in the current gasoline residue of CNG tank 2 (7.833 I x 8.628 kWh _H i per liter = 67.583 kWh _H i) and stores it in the additional data field 124 "Amount of Energy" of Gasoline Refueling Record 1676.

In step 25-A corresponding to step 6-A, the algorithm determines from the data field 125 "life cycle emission quota" of the last gasoline refueling record (not shown), which life cycle emission quota is calculated from the remaining gasoline remaining and the last gasoline Refueling the vehicle 1. This was 325.6 gC0 ₂ / kWh _H i (not shown). Thus, the algorithm up to and including record 1675 may be entered in the additional data field 125 "life cycle emission quota" of the "gasoline" records among the records 102, which life cycle emission quotas correspond to the energy inputs previously entered in the respective "gasoline" data sets (namely 325.6 gC0 ₂ / kWh _Hi each).

In step 26-A, which corresponds to step 07-A, the algorithm first multiplies the registered energy inputs 123 for the gasoline data records under the data sets 1653 to 1675 (ie for 1654, 1657, 1660, 1663, 1668, 1670 and 1674) per segment 121 with the life cycle emission quotas 124 recorded there, which gives the LCA-THG emission levels 125 of the "gasoline" data sets up to and including data set 1675, namely for the gasoline segment of the data set 1654: 611.9 gC0 ₂ , for the gasoline Part of the data set 1657: 200.0 gC0 ₂ , for DS 1660: 182.9 gC0 ₂ , for DS 1663: 163.5 gC0 ₂ , for DS 1668: 519.2 gC0 ₂ , for DS 1670: 8.596.4 gC0 ₂ , for DS 1674: 6.2 gC0 _2. These calculation results are written by the algorithm in the additional data field 126 "GHG emission quantity" of these data sets.

In step 27-A, corresponding to step 08-A, the algorithm divides the LCA-THG emission amounts from the additional data field 126 "GHG emission amount" per gasoline data set 102 whose data record number is <1676 (current refueling data record). through the respective segment (additional data field 121), which gives the C0 ₂ value per kilometer, which is entered in the additional data field 127 "gC0 ₂ / km" of the respective data set: 1654: 278 gC0 ₂ -eq / km , 1657: 250 gC0 ₂ -eq / km, 1660: 261 gC0 ₂ -eq / km, 1663: 272 gC0 ₂ -eq / km, 1668: 247 gC0 ₂ -eq / km, 1670: 239 gC0 ₂ -eq / km and 1674: 309 gC0 ₂ -eq / km.

In step 28-A, which corresponds to step 09-A, the algorithm computes the data for the gasoline residue of 7.831 liters located in gasoline tank 2 immediately prior to gasoline refueling 1676/1677, which is shown in data field 114 "gasoline level Tank 1 "of the record 1676. The algorithm asks from the last (not shown here) refueling record, which calorific value of the still in tank 1 before refueling 1676/1677 CNG remainder had .This value (8.628 kWh _H i / liter), the algorithm multiplies with that in data field 113 of the refueling Dataset 1676 listed residual gasoline quantity (7,831 liters). It stores the result (67.566 kWh _H i) in the additional data field 124 "energy amount" of refueling record 1676. In addition, the algorithm queries from data field 125 of the last gasoline refueling record (not shown) which life cycle emission quota the gasoline Residual amount of the last refueling record (not shown) (325.6 gC0 ₂ / kWh _H i, see step 25-A), multiplies this value by the value stored in the gasoline refueling record 1676 "Energy amount" additional data field 124 (67.583 kWh _H i, determined in step 24-A) and stores the result (22.005 gC0 ₂ ) in the additional data field 126 "GHG emission amount" of the refueling record

1676 from.

In a step 29-A corresponding to step 10-A, the algorithm determines by subtracting the data field 113 of the refueling record 1676 from the refueling record data field 113

1677 the fueled amount of fuel (17,304 liters of gasoline). This information is written by the algorithm in the data field "fuel refueling" of the refueling record "refueling 1676/1677", which is temporarily formed in the working memory.

From the refueling operation described by records 1676/1677, the algorithm is notified in a step 30-A corresponding to step 11-A from the GPS coordinates (not shown) that the refueling has taken place at the gas station A. (See the comments made above). He writes this information in the additional data field 128 "petrol station" of the two fueling records 1676 and 1677.

In a step 31-A, which corresponds to step 12-A, the algorithm from the gas station database 32 determines that this gas station A has dispensed the fuel sub-type "Super E10" at the time of refueling 1676/1677 of the vehicle 1 ( This information is written by the algorithm into the additional data field 119 "Fuel Subtype" of the refueling record 1677. Alternatively, this information is supplied by the front end 7 or by the switching device 61 with the transmitted data packet.

In step 32-A, which corresponds to step 13-A, the algorithm queries from the fuel database 31 and / or the petrol station database 32, which calorific value the on 03/04/2016 issued by the gas station A fuel subspecies "Super E10 This value (8.486 kWh _hi / liter) is multiplied by the algorithm with the quantity of gasoline refueled (17.304 liters, determined in step 29-A) from the data field "fuel refueling" of the refueling record "refueling 1676/1677 He writes the result (146.842 kWh _H i) in the data field "Fueled amount of energy" of the refueling record "Refueling 1676/1677" which was temporarily created in the main memory.

In step 33-A, which corresponds to step 14-A, the algorithm queries from the fuel data bank 31 and / or the gas station data bank 32, which life cycle emission quota the fuel subspecies, which was issued by the gas station A a on 03.04.2016 "Super E10" had and writes this value (315.7 gC0 ₂ / kWh _H i) in the data field "life cycle emission quota" of the refueling record "refueling 1676/1677" which was temporarily formed in the main memory.

In step 34-A, which corresponds to step 15-A, the algorithm multiplies the value entered in the data field "amount of energy" of the refueling record "refueling 1676/1677" temporarily formed in the main memory (146,842 kWh _Hi , determined in step 32-A). multiplies it by the value entered in the data field "life cycle emission quota" of the refueling data set "refueling 1676/1677", which has been provisionally stored in the main memory (315.7 gC0 ₂ / kWh _H i; Step 33-A) and stores the result (46,358.02 gC0 ₂ ) in the "GHG emission amount" data field of the refueling record "refueling 1676/1677" which is temporarily formed in the working memory.

In step 35-A, which corresponds to step 16-A, the algorithm adds the value stored in additional data field 124 "amount of energy" of refueling record 1676 (67.583 kWh _H i, determined in step 24-A) to the data field " Amount of energy "of the refueling record" refueling 1676/1677 "temporarily formed in the main memory (146.842 kWh _H i; determined in step 32-A) and stores the result (214.425 kWh _H i) in the additional data field 124" amount of energy "of the current one Refueling record 1677 from.

In step 36-A, which corresponds to step 17-A, the algorithm adds the value (22,005 gC0 ₂ ) determined in step 28-A and stored in additional data field 126 "GHG emission quantity" of refueling record 1676 to the data field " GHG Emission Amount "of the refueling record" refueling 1676/1677 "temporarily stored in memory (46,358.02 gC0 ₂ , determined in step 34-A) and stores the result (68,363 gC0 ₂ ) in data field 126" GHG emission amount from refueling record 1677.

In step 37-A, which corresponds to step 18-A, the algorithm divides the value stored in additional data field 126 "GHG emission amount" of the current refueling record 1677 (68,363 gC0 ₂ , determined in step 36-A) by that in the data field 124 "energy amount" of the fueling data record 1677 stored value (214.425 kWh _H i; determined in step 35-A) and stores the result (318.82 GC0 ₂ / kWh _H i) in the additional data field "life cycle emission ratio" of the refueling 125 Record 1677 from.

In step 38-A, which corresponds to step 19-A, the algorithm deletes the no longer needed, temporarily in-memory record "refueling 1676/1677" and goes in the event that there are other gasoline records or gasoline refueling, for a new pass B to step 23. In the event that there are no more gasoline data sets, the algorithm goes to step 39.

In step 23-B, which corresponds to step 04-E, the algorithm for the fuel main type gasoline from the fill level of the tank 2 (data field 114) and possibly also on the occasion (data field 109) determines the parts which are connected to the Gasoline tank contents have been covered, which has resulted from the last gasoline refueling 1676/1677. The tank content resulting from refueling is composed of the remaining fuel in the tank and the added amount of refueling. Since after refueling 1676/1677 the next gasoline refueling stop is not yet documented, the algorithm concludes that all gasoline stretches with a data record number> 1677 were covered with the tank contents, which resulted from refueling 1676/1677. So it's the gasoline records 1678 (consumption 0.026 liters), 1680 (4.845 liters), 1683 (0.152 liters), 1688 (0.020 liters), 1691 (0.140 liters), 1693 (2.890 liters), 1697 (0.020 liters). 1699 (0.028 liter), 1703 (0.170 liter), 1706 (0.162 liter), 1710 (0.200 liter), 1713 (0.134 liter), 1718 (0.024 liter), 1722 (0.167 liter) and 1725 (0.122 liter). In the exemplary embodiment of FIG. 25, gasoline sections that are in the tank 2 are used for this gasoline sections after the last gasoline refueling, which was consumed except for a remainder of 16.037 liters. From the last gasoline refueling 1676/1677 the algorithm is known that the last tank contents consisted of a mixture of Super E5 and Super E10.

In step 24-B corresponding to step 05-E, the algorithm determines the level 114 (25.135 liters, see record 1677) and the additional data field 124 (amount of energy; 214.425 kWh _H i, determined in step 16-A) of last fueling record 1677 by dividing the average specific energy content of the gasoline tank 2 of the vehicle 1 located gasoline mixture. This amounts to 8.531 kWh _H i per liter. Thus, the algorithm from record 1678 to record 1728 inclusive can enter into the additional data field 124 "amount of energy" of the "gasoline" data sets among the data records 102, which energy inputs in step 03 in the additional data field 123 "gasoline amount" of Gasoline volumes recorded in respective CNG records correspond to: 1678 (consumption 0,222 kWh _Hi ), 1680 (41,333 kWh _Hi ), 1683 (1,297 kWh _Hi ), 1688 (0,166 kWh _Hi ), 1691 (1,190 kWh _Hi ), 1693 (24,655 kWh _Hi ), 1697 (0.166 kWh _Hi ), 1699 (0.238 kWh _Hi ), 1703 (1.450 kWh _Hi ), 1706 (1.382 kWh _Hi ), 1710 (1.702 kWh _Hi ), 1713 (1.146 kWh _Hi ), 1718 (0.203 kWh _Hi ), 1722 (1.426 kWh _H i) and 1725 (1.037 kWh _H i) Since there is no new refueling record, the algorithm calculates no current gasoline remainder.

In step 25-B corresponding to step 6-E, the algorithm retrieves from data field 125 "life cycle emission quota" of the last gasoline refueling record 1677 which (new) average life cycle emission quota is from the remaining gasoline remaining and the last Petrol refueling of the vehicle 1. This was 318.8 gC0 ₂ / kWh _H i (determined in step 37-A). Thus, the algorithm FROM record 1678 through record 1728 may be inserted into the additional data field 125 "life cycle emission quota" of the "gasoline "Records among the data sets 102 (in the flow B so in the records 1678, 1680, 1683, 1688, 1691, 1693, 1697, 1699, 1703, 1706, 1710, 1713, 1718, 1722, and 1725 enter which life cycle emission rates the previously included in the respective "gasoline" datasets (namely 318.8 gC0 ₂ / kWh _Hi each).

In step 26-B, which corresponds to step 07-E, the algorithm for the gasoline data sets among the data sets 1678 to 1728 (ie for 1678, 1680, 1683, 1688, 1691, 1693, 1697, 1699, 1703, 1706, 1710, 1713, 1718, 1722, and 1725) lists the ener- gy inputs 123 per segment 121 with the life cycle emission quotas 124 entered therein, which gives the LCA-THG emission levels 125 of the "gasoline" data sets up to and including data set 1728, namely for the gasoline Part of the data set 1678: 70.7 gC0 ₂ , for 1680: 13.176.9 gC0 ₂ , for 1683: 413.4 gC0 ₂ , for 1688: 53.0 gC0 ₂ , for 1691: 379.4 gC0 ₂ , for 1693: 7859.9 gC0 ₂ , for 1697: 53.0 gC0 ₂ , for 1699: 75.9 gC0 ₂ , for 1703: 462.3 gC0 ₂ , for 1706: 440.6 gC0 ₂ , for 1710: 542.6 gC0 ₂ , for 1713: 365.3 gC0 ₂ , for 1718: 64.6 gC0 ₂ , for 1722: 454.7 gC0 ₂ and for 1725: 330.4 gC0 _2. These computation results are written by the algorithm into the additional data field 126 "THG". Emissionsme data sets 1678, 1680, 1683, 1688, 1691, 1693, 1697, 1699, 1703, 1706, 1710, 1713, 1718, 1722, and 1725.

In step 27-B corresponding to step 08-E, the algorithm divides per gasoline record 102 whose record number is> 1677 (last gasoline refueling record) (ie for 1678, 1680, 1683, 1688, 1691, 1693, 1697, 1699, 1703, 1706, 1710, 1713, 1718, 1722, and 1725), the LCA-THG emission amounts from the additional data field 126 "GHG emission amount" through the respective sub-section (additional data field 121), which is the C0 _2nd This value is entered by the algorithm in the additional data field 127 "gC0 ₂ / km" of the respective data set: 1678: 354 gC0 ₂ -eq / km, for 1680: 231 gC0 ₂ -eq / km, for 1683 : 258 GC0 ₂ eq / km for 1688: 354 GC0 ₂ eq / km for 1691: 253 GC0 ₂ eq / km for 1693: 231 GC0 ₂ eq / km for 1697: 354 GC0 ₂ eq / km, for 1699: 253 gC0 ₂ -eq / km, for 1703: 231 gC0 ₂ -eq / km, for 1706: 245 gC0 ₂ -eq / km, for 1710: 258 gC0 ₂ -eq / km, for 1713: 215 GC0 ₂ eq / km, for 1718: 258 GC0 ₂ eq / km, for 1722: / km 239 GC0 ₂ eq and f r 1725: 220 GC0 ₂ eq / km.

In step 28-B corresponding to step 09-E, the algorithm does not calculate data for the gasoline residue in gasoline tank 2 because there is no next gasoline refueling record. In a step 29-B corresponding to step 10-E, the algorithm determines nothing because there are no more gasoline refueling records.

In step 30-B corresponding to step 11-E, the algorithm calculates nothing because there are no more gasoline refueling records.

In step 31-B corresponding to step 12-E, the algorithm calculates nothing because there are no more gasoline refueling records.

In step 32-B corresponding to step 13-E, the algorithm calculates nothing because there are no more gasoline refueling records.

In step 33-B corresponding to step 14-E, the algorithm calculates nothing because there are no more gasoline refueling records.

In step 34-B corresponding to step 15-E, the algorithm calculates nothing because there are no more gasoline refueling records.

In step 35-B corresponding to step 16-E, the algorithm calculates nothing because there are no more gasoline refueling records.

In step 36-B corresponding to step 17-E, the algorithm calculates nothing because there are no more fueling records.

In step 37-B, which corresponds to step 18-E, the algorithm calculates nothing because there are no more fuel refueling records.

In step 38-B, which corresponds to step 19-E, the algorithm does not clear anything since it has not formed a temporary fueling record "refueling XYZ." Since there are no further unprocessed gasoline records after run B, the algorithm proceeds to step 39.

The gasoline refueling listed in the ohdata list 200 has defined a total of 2 data areas with partial stretches covered by the fuel main type gasoline ("gasoline" data sets), namely the data areas A (data records 1653-1675) and B (data records 1653-1675). Data sets 1678-1728) Since the technical data (energy content or calorific value, GHG emission quota, GHG emission quantity) of the contents of the gasoline tank 2 can change with each refueling, the refueling record must always first be evaluated before the subsequent data sets describing the gasoline segments can be supplemented with data on energy use and GHG emissions, as described above (ie first for a refueling record and then for the subsequent data range up to the next refueling record, etc.) or, alternatively, first for all gasoline refueling records and then for all "gasoline" data sets, where the A For the supplementation of the gasoline data records, the respective refueling system and its data records are accessed. In order to avoid repetition, this alternative approach, which incidentally can also be used to supplement "diesel" and other fuel type-specific data sets, is not presented here, but it should be included in the scope of protection, regardless of which fuel Similarly, it is intended to be within the scope of the invention if the steps of data set completion and / or data computation are performed in any other order than that described herein.

The algorithm according to the invention has also calculated in step 02 for each "gasoline" partial sections of the raw data extract 200 the respective partial section length 121, in step 22 the respective segment fuel consumption, in step 24 the respective route-specific energy input 124, in step 26 the respective route-specific GHG emission quantity 126 and in step 27 the respective route-specific GHG emission quota 127 in gC0 ₂ -eq / km. Except for the GHG emission quota 127, the algorithm adds this segment-specific data to gasoline-specific summation values in step 39. For the "gasoline" data sets 1654, 1657, 1660, 1663, 1668, 1670, 1674, 1678, 1680, 1683, 1688, 1691, 1693, 1697, 1699, 1703, 1706, 1710, 1713, 1718, 1722, and 1725 results in the addition of the section lengths 121 a gasoline total distance of 148.6 km _BENZ | _N. The addition of the individual measured in liters of gasoline consumption 123 results in a total consumption of 12.757 liters of gasoline of different qualities - Amounts 124 results in a total use of 109.184 kWh _H i and the addition of the individual GHG emission amounts 126 a total emission of 35.023 gC0 ₂ equivalents These total values are calculated according to causation, are not based on average or average values, but take into account the technical data of the Used different fuel subspecies 119.

In step 40, the algorithm calculates the specific quota values for the fuel main type gasoline, namely the route-specific energy input, which is 109.184 kWh _H i / 148.6 km = 0.735 kWh _H i / km, the energy-specific GHG emission quota, which is 35,023 gC0 ₂ / 109,184 kWh _H i = 320,8 gC0 ₂ / kWh _H i, and the route-specific GHG emission quota, which is 35,023 gC0 ₂ / 148,6 km = 235,7 gC0 ₂ / km calculated.

In step 41, the algorithm adds the subtotals determined per fuel main type to total values. For the distance traveled, there are 1,446.3 km + 148.6 km = 1,594.9 km, for the total energy input 1,115.8 kWh _Hi + 109.2 kWh _Hi = 1.225.0 kWh _Hi and for the LCA-THG emission quantity 182,083 gC0 ₂ + 35,023 gC0 ₂ = 217,106 gC0 ₂ .

In step 42, the algorithm computes the specific quota values for both major fuel types, namely the average route-specific energy input, which is 1,225 kWh _H i / 1,594.9 km = 0.768 kWh _H i / km, the energy-specific GHG emission quota , which amounts to 217,106 gC0 ₂ / 1,225,0 kWh _Hi = 177,2 gC0 ₂ / kWh _Hi , and the route-specific GHG emission quota, which is 217,106 gC0 ₂ /l.594,9 km = 136 gC0 ₂ / km calculated. This value of 136 gC0 ₂ / km differs considerably from the value calculated above with an average of 197 gC0 ₂ / km (see above). The procedure according to the invention or the algorithm according to the invention thus provide substantially better results and technical data - which was the stated (technical) task of the invention.

In step 43, the algorithm calculates the (LCA) GHG emission amount that would have been produced using any reference fuel, preferably when using the reference fuel regular gasoline. To do this, the algorithm queries the corresponding (LCA) GHG emission quota value from the fuel file / database 31. For regular gasoline it is 335.9 gC0 ₂ -eq / kWh _H i. This value is multiplied by the total energy input (1,225.0 kWh _H i) determined in step 41. The result (411.477.5 gC0 ₂ ) is saved for further calculations.

In step 44, the algorithm calculates the difference between the reference (LCA) GHG emissions determined in step 43 and the LCA-GHG emissions detected in step 41, which are 411,477.5 gC0 ₂ ./. 217.106 gC0 ₂ = 194.371.5 gC0 ₂ . This difference is the greenhouse gas reduction performance that the vehicle 1 has provided over the distance traveled.

In step 45, the algorithm calculates the one kilometer reference quota for the GHG emission of the vehicle 1. For this, the reference emission determined in step 43 is determined by the divided by the vehicle 1, giving 411,477.5 gC0 ₂ /l.594.9 km = 258 gC0 ₂ / km.

In step 46, the algorithm sets the greenhouse gas reduction performance determined in step 44 in relation to the reference (LCA) GHG emission determined in step 43, which gives the percent GHG reduction performance of the vehicle 1. This is 194,371.5 gC0 ₂ / 411,477.5 gC0 ₂ = 47.2%. Alternatively, the algorithm sets the difference between the one kilometer reference C0 ₂ emission determined in step 45 and the one kilometer C0 ₂ emission determined in step 42 in relation to step one kilometer Reference C0 ₂ emission, which gives (258 ./136) / 258 = also 47.2%.

In step 47, the algorithm waits for another front end 7 to supply new records 102 for calculation. In this case, the algorithm according to the invention starts again with step 1.

In the embodiment described in FIGURE 25, the back-end 22 is thus provided raw data sets 102. In the backend 22, these raw data are supplemented with calculation results. The data sets supplemented with these calculation results are stored in the vehicle file / database 30, where they are henceforth available for data analyzes, customary statistical evaluations and data aggregations of any kind.

If the vehicle owner or driver does not want the vehicle locations to be determined, a work instruction of the front end 7 may include determining geographic coordinates for refueling records only. Accordingly, a work instruction of the back-end 22 may include deleting in the data records all transmitted geographic coordinates which are not related to refueling.

The procedure described herein for determining the actual (LCA) GHG emission of a vehicle 1 can also be used to the actual NO _x - to determine the particulate matter emissions of a vehicle 1 and / or. This may be done by supplementing the fuel file / database 31 with fuel or energy specific NO _x levels and / or fuel or energy specific particulate matter quota values and the algorithm based the corresponding emissions according to the procedure described above determined on the respective fuel consumption and / or energy use.

Alternatively, the actual NO _x and / or PM emissions may be determined by appropriate sensors measuring NO _x levels or particulate matter parameters on the exhaust gas volumetric flow or exhaust gas mass flow, and directly or indirectly communicating these values from the front end 7 Back end 22 are transmitted, where the algorithm determined from these values route-specific absolute NO _x emissions or particulate matter emissions, which are then related to traveled routes and the corresponding quota values per kilometer result.

FIGURE 26 illustrates a simplified algorithm 170 for calculating fuel consumption, energy use, and (LCA) GHG emissions. It can be used when the vehicle 1 only refuels a main fuel type or when the users of the calculation results satisfy an (approximate) average consideration. This embodiment of the algorithm, which is only one of many, includes 15 steps. Since it will be obvious to a person of ordinary skill in the art, after considering the invention, to replace this algorithm with a similar one, not only will protection be provided for the algorithm 170 described herein, but also for modified algorithms 170 ^' based on the basic approach disclosed herein.

In step 1, the front end 7 installed in a vehicle 1 generates for each fueling two fueling data sets including GPS coordinates, odometer reading and date, namely a refueling record at the beginning of refueling and a refueling record immediately after completion of refueling refueling.

In step 2, a comparison of the GPS coordinates of the refueling location with the GPS coordinates of all filling stations contained in a refueling point file 32 is already carried out in the front end 7. The gas station file 32 is stored in the front-end 7. The comparison identifies the filling station at which the vehicle 1 was refueled.

In step 3, a comparison of the refueling date is made with the times at which the gas stations has changed the fuel subtype. In the gas station file 32 is stored per main fuel type, which fuel subspecies is being delivered from each gas station. The required updates to the gas station file 32 may e.g. be carried out by regular data transfers from a back-end 22 to the front-end 7, wherein this transmission directly from the back-end 22 on the front-end 7 or indirectly from the back-end 22 via the switching device 61 (Smartphone 8) on the front End 7 can be done. The comparison of step 3 produces the fuel subtype fueled by the vehicle 1.

In step 4, the algorithm retrieves from a fuel file 31 the relevant technical data of the fuel subtype identified in step 3 and stores it in the refueling record. The fuel file 31 is stored in the front-end 7. The technical data include the energy content (lower heating value Hi) and the (LCA) GHG emission quota of the identified fuel subtype, which is preferably given in gC0 ₂ -eq / kWh _H i (gC0 ₂ -eq / MJ), but also may be indicated in gC0 ₂ - eq / sales unit.

In step 5, the algorithm determines the distance traveled by the vehicle 1 since the last fueling by subtracting the odometer reading of the last refueling record from the odometer reading of the refueling record currently being processed.

In step 6, the algorithm calculates the fuel consumption that the vehicle 1 has had between the refueling currently in progress and the last refueling. This value is determined by the algorithm by subtracting the tank level from the tank level at the time of commencement of the refueling currently in progress at the time of the completion of the last refueling.

In step 7, the algorithm calculates the energy input made between the refueling. This is determined by the algorithm multiplying the fuel consumption determined in step 6 by the energy content value (lower heating value Hi) stored in step 4 in the last refueling record. The result is an energy input.

In step 8, the algorithm calculates the (LCA) GHG emission amounts that have arisen from fuel consumption between refueling. This is done by the algorithm preferably multiplying the amount of energy input determined in step 7 by the value for the energy-specific (LCA) emission quota stored in step 4 in the last refueling record. Alternatively, the algorithm may multiply the fuel consumption determined in step 6 by the sales unit (LCA) GHG emissions quota. In both cases, the result is an (LCA) GHG emission amount. In step 9, the algorithm calculates the route-specific values for fuel consumption. This is done by the algorithm dividing the determined in step 7 amount of energy use by the determined in step 5 driving distance. Results are the fuel consumption (measured in sales units) per kilometer or per 100 kilometers or the range measured in kilometers or miles per sales unit (gallon).

In step 10, the algorithm calculates the route-specific values for the energy input. This is done by dividing the amount of energy used in step 7 by the distance determined in step 5. The result is the energy used per kilometer or per 100 km.

In step 11, the algorithm calculates the route-specific values for the (LCA) GHG emission. This is done by dividing the (LCA) GHG emission quantity determined in step 8 by the distance determined in step 5. Alternatively, the algorithm may multiply the route-specific energy input determined in step 10 by the (LCA) GHG emission quota stored in step 4 in the last refueling record. Another option for determining the route-specific value for the (LCA) GHG emission is to multiply the route-specific fuel consumption value determined in step 9 by the unit-to-unit (LCA) GHG emission quota. In all cases, the result is the one kilometer GHG emission, which is usually measured in gC0 ₂ / km.

In step 12, the algorithm calculates the (LCA) GHG emission amount that would have been produced using any reference fuel, preferably when using the reference fuel regular gasoline. To do this, the algorithm queries the corresponding (LCA) GHG emission quota value from the fuel file / database 31. This value is multiplied by the energy input determined in step 10. The result is saved for further calculations.

In step 13, the algorithm calculates the difference between the reference (LCA) GHG emission determined in step 12 and the LCA GHG emission amount determined in step 8. This difference is the greenhouse gas reduction performance that the vehicle 1 has provided over the distance traveled.

In step 14, the algorithm calculates the one kilometer reference quota for the GHG emission of vehicle 1. For this purpose, the reference emission determined in step 12 is divided by the distance traveled by vehicle 1 (determined in step 5).

In step 15, the algorithm sets the greenhouse gas reduction performance determined in step 13 in relation to the reference (LCA) GHG emission determined in step 12, which gives the percent GHG reduction performance of the vehicle 1. Alternatively, the algorithm sets the difference between the one kilometer reference C0 ₂ emission determined in step 14 and the one kilometer C0 ₂ emission determined in step 11 in relation to the one kilometer determined in step 14 Reference CO ₂ emission.

These results determined by the front-end 7 can be transmitted to a switching device 61 (smartphone 8) or a back-end 22 or another point for forwarding or viewing by a user. Preferably, a smartphone app is provided which receives the results calculated by the front-end 7 and transmitted to the smartphone 8 and visualized to the smartphone user.

Alternatively, the front-end 7 may also transmit the above-described refueling data to the switch 61 (the smartphone 8), preferably via Bluetooth, and an algorithm integrated into a corresponding app will perform the above calculations there. FIGURE 27 shows one of many possible embodiments of a report 180 to illustrate the actual fuel consumption incurred in everyday use of a vehicle 1, the corresponding energy input, the corresponding (LCA) GHG emissions, and the corresponding NO _x and particulate emissions. The report may be prepared on the occasion of the expiration of a particular period (day, week, month, quarter, year, etc.), or on a particular occasion (completion of a trip, trip, etc.), at specific times, or as required by whom always. In the header area 131 vehicle master data, such as the vehicle ID, the license plate, the vehicle owner and an arbitrary wide range of other vehicle master data can be displayed. In the data area 132, the desired result data are shown.

In the exemplary embodiment shown, which is only one of many possible embodiments, the results of a dual CNG vehicle 1 are shown in the data area 132 for a specific period 133 (in this case for the month of April 2016 as monthly report 34). For better illustration, the results shown here are based on the data of the example shown in FIG. 25, assuming for the sake of simplification that the corresponding CNG vehicle 1 was not moved further in the month of April 2016 than shown in FIG.

The result parameters include: the total distance traveled 134 in the reporting period 133, the portion 135 traveled in the CNG mode, the portion 136 traveled by the dual CNG vehicle 1 in the gasoline mode, which is based on the distance traveled 135 Consumption of the first main fuel 137 (CNG in this case), the consumption of CNG 138 on the route segment 135, the consumption of BioMethan 139 on the route segment 135, the share of SynMethan 141 consumed in the route section 135, consumption ^{proportion of} methane ^ZeroEmission 142 attributable to the route section 135, the consumption ^{share of} the second main fuel 143 (in this case gasoline) incurred on the traveled route 136, the consumption of normal gasoline 144 attributable to the route section 136, which is based on the route segment 136 consumable consumption Part of Super E5 145, the consumption share of Super E10 146 attributable to the route section 136, the consumption share of Super V-Power 147 attributable to the route section 136, the total amount of energy 148 used on the total distance covered 134, the amount of energy used for the first fuel - main type 149 (in this case CNG), the amount of energy used in CNG 151, the amount of energy used in BioMethan 152, the amount of energy used in SynMethan 153, the amount of energy used in methane ^ZeroEmisslon 154, the amount of energy used for the second main fuel 155 (in in this case, gasoline), the amount of energy used in normal gasoline 156, the amount of energy used on Super E5 157, the amount of energy used on Super E10 158, the amount of energy used in Super V-Power 159, the total amount of energy used per total kilometer 161, the used amount of energy per kilo ometer in the first main fuel 162, the amount of energy used per kilometer in the second main fuel 163, the total (LCA) GHG emissions 164, the emission amount of the first main fuel 165, the emission amount of the second main fuel 166 , the emission quota caused by CNG 167, the emission level caused by BioMethan 168, the emission level caused by SynMethan 169, the emission level caused by methane ^ZeroEmisslon 171, the ^{fraction of ordinary} gasoline 172, the ^{fraction of superhighs} caused by Super E5 173, that of Super E10 Emission quota 174; Super V-Power's emission quota 175, the average total emission quota per total kilometer 176, the emission quota per kilometer of the first main fuel 177, the emissions quota per kilometer of the second main fuel 178, the CNG emission quota per CNG kilometer 179, the bio methane emission quota per biomethane kilometer 181, the SynMethan emission quota per SynMethan kilometer 182, the methane ^zero ^emission quota per methane ^ZeroEmission kilometer 183, the regular gasoline emission quota per standard petrol kilometer 184, the super E5 emission quota per Super E5 kilometer 185, the Super E10 emission quota per Super E10 kilometer 186, the Super V-Power emission quota per Super V-Power kilometer 187 , the reference emission quota per total kilometer 188, the greenhouse gas reduction performance as emission quota per total kilometer 189, the greenhouse gas reduction performance as a percentage 191, the official fuel consumption per kilometer relative to the first main fuel grade (here CNG) 192 , the official fuel consumption per kilometer based on the second main fuel type (here gasoline) 193, the official energy use per kilometer relative to the first fuel Ha uptart (here CNG) 194, the official energy input in relation to the second main fuel type (here gasoline) 195, the actual energy input in CNG mode in relation to 100 km 196, the actual energy use in gasoline mode relative to 100 km 197, the absolute difference between official and actual energy input in CNG mode 198, the relative difference between official and actual energy use in CNG mode 199, the absolute difference between official and actual energy use in petrol mode 201, the relative difference between official and actual energy use in the Gasoline mode 202, the official C0 ₂ emission value per kilometer in CNG mode 203, the official C0 ₂ emission value per kilometer in gasoline mode 204, the absolute difference between official and actual GHG emission in CNG mode 205, the absolute difference between official and actual GHG emissions in gasoline mode 206, the relative difference between official and actual GHG emission per kilometer in CNG mode 207, the relative difference between official and actual GHG emission per kilometer in gasoline mode 208, the total amount of total NO _x accumulated over the whole route 134, the NO _x Emission amount 211 attributed to the CNG mode 135 (CNG mode), the NO _x emission amount 216 attributed to the travel distance portion 136 and the gasoline mode, respectively, is the average NO _x emission rate per Total kilometer 217, the relative NO _x emission quota per kilometer for the first main fuel 218 (here CNG), the relative NO _x emission quota per kilometer for the second main fuel 219 (here gasoline), the official NO _x - Emission quota per CNG kilometer 221, the official NO _x emissions quota per gas mileage 222, the absolute difference between the official and actual NO _x emission quota with reference to the CNG mode 223, d The absolute difference between official and actual NO _x emission quota relative to gasoline mode 224, the relative difference between official and actual NO _x emission quota relative to CNG mode 225, the relative difference between official and actual NO _x Emission quota based on the gasoline mode 226, the total total particulate matter emission amount 227 incurred over the entire route 134, the particulate matter emission quantity 228 attributable to the CNG mode or to the route share 135, the particulate matter emission quantity 229, the gasoline mode or route share 136, the average relative particulate emissions quota per total kilometer 231, the relative particulate emissions quota per kilometer for the first main fuel 232 (here CNG), the relative fine particulate emissions quota per kilometer Kilometer for the second major fuel type 233 (here gasoline), the official fine particulate emission quota per CNG kilometer 23 4, the official fine dust emission quota per petrol kilometer 235, the absolute difference between official and actual particulate matter emission quota relative to CNG mode 236, the absolute difference between official and actual particulate matter emission quota relative to gasoline mode 237, Relative difference between official and actual particulate emissions quota based on CNG mode 238, the relative difference between official and actual particulate emissions quota based on gasoline mode 239. The total travel distance 134 is determined by adding all the legs (whose determination is included in the description of FIG. 25) or by subtracting the odometer 117 at the end of the previous month from the odometer 117 at the end of the current month. The running distance 135 traveled in the CNG mode during the reporting period is determined by adding all the distances covered by the fuel main type "CNG" (refer to FIG.25) Accordingly, the travel distance 136 traveled by the CNG vehicle 1 in the gasoline mode becomes addition all calculated with the main fuel type "gasoline" sections calculated (see description for FIGURE 25).

Consumption of the main fuel type "CNG" 137 is determined by subtracting from the level of the CNG tank at the end of the month (6.146 kg) the level at the beginning of the month (9,500 kg), resulting in a stock loss and ergo fuel consumption of 3,354 kg the quantities of fuel added (refueling 1 = 21.152 kg, 2 = 20.916 kg, 3 = 20.441 kg, 4 = 17.477 kg) are added, so that the consumption of CNG route 135 is 83.3 kg.

The consumption of the fuel subspecies "CNG" is calculated accordingly, provided that the composition of the CNG mixture contained in the CNG tank at the end of the month is known, since the CNG vehicle 1 of the example of FIG fueled with an 80:20 mixture of CNG and BioMethane, as well as pure methane and methane ^ZeroEmisson, calculated as follows: The 9,500 kg gaseous fuel contained in the CNG tank at the beginning of the month consisted of 100% pure CNG , accordingly also the remainder I (0.348 kg) contained in the CNG tank before the first refueling, with 21.152 kg of pure CNG being fueled, so that the tank level after the first refueling was also made of pure CNG.

The gas fuel residue II contained in the CNG tank before the 2nd refueling was also 100% pure CNG. However, the quantity of 20.916 kg refueled was composed of 80% (16.733 kg) of CNG and 20% (4.183 kg) of BioMethane. Thus, the new gas mixture after the 2nd refueling was 4.183 kg (19.547%) from BioMethane and 17.217 kg (80.453%) from CNG. Accordingly, the residual stock III remaining in the CNG tank prior to the third refueling was 0.708 kg, 0.199 kg (19.547%) of bio methane and 0.570 kg (80.453%) of CNG. 20,580 kg of BioMethane were refueled at the 3rd refueling so that the new gas mixture of a total of 21,150 kg was composed of 0,570 kg (2,695%) of CNG and 20,580 kg (97,305%) of BioMethane.

Before the 4th refueling the CNG tank contained a residual IV of 2,413 kg. The CNG content was 2.695% (0.065 kg) and the proportion of BioMethane 97.305% (2.348 kg). Were fueled 17.447 kg methane ^{Zero Emission,} so that the new gas mixture of 19,860kg to 2.348 kg (11.823%) from BioMethan, 0.065 kg (0.327%) of CNG and 17.447 kg (87.850%) consisted of methane ^{Zero Emission.} This composition was also exhibited by the end of the month CNG tank V, of which 6.146 kg was 11.823% (0.727 kg) of BioMethane, 0.347% (0.020 kg) of CNG and 87.850% (5.399 kg) of methane ^{zero emission} ,

Knowing the composition of the initial and final contents of the contents of the CNG tank, the fuel consumptions can be determined to be specific to the type. For the fuel subspecies CNG there were at the end of the month. At the beginning of the month, there was a stock reduction of 9,500 kg to 0,020 kg, ie of 9,480 kg. Together with the refueled tank quantities of 21,152 kg for refueling 1 and 16,733 kg for refueling 2 (see above), this results in CNG consumption 138 of 47,365 kg. With the fuel subspecies BioMethan there was a stock build-up of 0.727 kg between the beginning of the month and the end of the month. Together with the refueled tank volumes of 4.183 kg and 20.441 kg, this results in an effective BioMethane consumption 139 of 23.897 kg. For the methane ^ZeroEmission is a effective consumption 142 of 17,447 kg ./. 5,399 kg = 12,048 kg. Syn methane 141 was not used.

At petrol tank the procedure for determination of composition of initial and final contents of contents of gasoline tank is basically the same. The consumption of the main fuel type "petrol" 143 is determined by subtracting from the level of the petrol tank at the end of the month (16,037 liters) the level at the beginning of the month (11,490 liters), which results in an inventory of 4,547 liters Refueled fuel quantity (refueling 2 = 17.304 liters) subtracted, so that there is a consumption of 12.757 liters for the gasoline route 136.

Prerequisite, however, is the knowledge of the composition of the end of the period contained in the gasoline tank gasoline mixture, because the CNG vehicle 1 of the example of FIGURE 25 was driven in the month under review with both Super E5 and Super E10. The calculation of this composition is as follows: The 11,490 liters of liquid fuel contained at the beginning of the period in the gasoline tank consisted of 100% Super E5, accordingly also contained before the 2nd refueling in the gasoline tank residue I of 7.831 liters. The initial inventory of 11,490 liters consisted of 95% (10,916 liters) of normal gasoline and 5% (0.575 liters) of bioethanol. Accordingly, before the first gasoline refueling with Super E10 (this is the second total refueling), the remaining of the petrol tank was 7,831 liters to 95% (7,439 liters) of regular gasoline and 5% (0,392 liters) made of bioethanol. Refueling was 17.304 liters of Super E10, which consists of 10% (1.730 liters) of bioethanol and 90% (15.574 liters) of regular gasoline. The resulting after the first gasoline refueling new tank level of 25.135 liters thus consisted of 0.392 liters + 1.730 liters = 2.122 liters (8.442%) of bioethanol and 7.449 liters + 15.574 liters = 23.013 liters (91.558%) of regular gasoline. Accordingly, the gasoline balance at the end of the period amounted to 16.037 liters to 91.558% (14.683 liters) of regular gasoline and 8.442% (1.354 liters) of bioethanol.

Based on the gasoline sub-types Super E5 and Super E10 resulted in the composition of the existing gasoline tank gasoline change as follows: Both the beginning of the beginning of the period (11.490 liters) and the remaining stock (7.831 liters) before the gasoline refueling consisted of 100% Super E5. After the addition of 17.304 liters of Super E10 in the gasoline tank, its new content of 25.135 liters to 68.844% from Super ElO and 31.156% from Super E5. At the end of the period of 16,037 liters, the petrol residue also consisted of 31.156% (4.996 liters) of Super E5 and 68.844% (11.041 liters) of Super ElO.

With knowledge of the composition of the beginning and the end of the contents of the gasoline tank, the fuel consumption can be determined specific to the type. The fuel sub-type Super E5 was at the end of the month. At the beginning of the month, a stock reduction of 11.490 liters by 6.494 liters to 4.996 liters. In addition, there was an inventory build on Super E10 from 0.000 liters to 11.041 liters. Since no Super E5 was fueled, this fuel sub-type Super E5 145 results in a fuel consumption of 6.494 liters. The consumption of Super E10 146 is calculated from the amount of fuel (17.304 liters) minus the inventory (11.041 liters) = 6.263 liters. The fuel sub-types Pure Regular Gasoline 144 and Super V-Power 147 were not consumed.

The energy input is calculated from the fuel consumption of the individual fuel sub-types, which are multiplied by their energy content or their (lower) calorific values. These specifications are provided by the fuel database 31. The volume-specific calorific value of the fuel subtype CNG 138 in this embodiment, which is only one of many, is 13.393 kWh _H i / kg. Incidentally, this is also the calorific value of the fuel sub-types BioMethane 139, SynMethan 141 and Methane Zero Emission 142. By multiplying the fuel quantity The (lower) calorific value can be used to calculate the energy input quantities. For the CNG fuel subtype, the CNG energy input 151 is 47.365 kg x 13.393 kWh _H i / kg = 634.359 kWh _Hi . For the bio-methane fuel type, the BioMethane energy input 152 is 23.897 kg x 13.393 kWh _Hi / kg = 320.053 kWh _Hi . The SynMethan fuel subtype results in a syn methane energy input 153 of 0.000 kg x 13.393 kWh _Hi / kg = 0.000 kWh _Hi . For the methane ^ZeroEmission fuel subtype, a methane ^ZeroEmission energy ^input 154 of 12.048 kg x 13.393 kWh _H i / kg = 161.359 kWh _H i results. The energy input for the entire CNG mode 149 is given by adding the energy inputs of the gaseous fuel subtypes, ie 634,359 + 320,053 + 161,359 = 1,115,771 kWh _Hi .

The volume-specific calorific value of the fuel sub-type Super E5 145 in this embodiment, which is only one of many possible, is 8.628 kWh _H i / liter. The calorific value of the fuel sub-type Super E10146 in this embodiment is 8.531 kWh _H i / liter. This data also provides the fuel database 31. By multiplying the fuel quantity with the calorific value, the energy input quantities can be calculated. For the fuel sub-type Super E5, this results in a Super E5 energy input 157 of 6.494 liters x 8.628 kWh _H i / liter = 56.030 kWh _H i. For the fuel sub-type Super E10 results in a Super E10 energy input 158 of 6.263 liters x 8.531 kWh _hi / liter = 53.430 kWh _Hi . For the fuel subspecies normal gasoline results in a regular gasoline energy input 156 of 0.000 liters x 8.770 kWh _H i / liter = 0.000 kWh _{H |} , For the fuel sub-type Super V-Power results in a super V-power energy input 159 of 0.000 liters x 8.770 kWh _H i / liter = 0.000 kWh _{H |} , The energy input for the entire gasoline mode 155 is obtained by adding the energy input quantities of the liquid fuel subtypes, ie 56.030 + 53.430 = 109.460 kWh _H i. The total energy input 148 is calculated by adding the energy input of the CNG mode 149 (1,115,771 kWh _H i) and the energy input of the gasoline mode 155 (109,460 kWh _Hi ), yielding 1,225,231 kWh _Hi .

The total average energy input per kilometer 161 is calculated by dividing the total energy input 148 by the total distance 134, which yields 1,225.231 kWh _H i / 1,595 km = 0.768 kWh _H i / km. The route specific energy input 162 incurred in CNG mode is determined by dividing the amount of energy input of CNG mode 149 (1,115,771 kWh _H i) by distance 135 (1,446 km) traveled in CNG mode, which is 0,772 kWh _H i / km results. The gasoline mode route-specific energy input 163 is determined by dividing the energy input of the gasoline mode 155 (109.460 kWh _H i) by the gasoline mode distance 136 (149 km), which is 0.735 kWh _hi / km.

The (LCA) GHG emission levels are calculated by multiplying the fuel subspecies specific energy input amounts by the fuel-subspecies-specific (LCA) GHG emission values. These emissions values are provided by the fuel database 31. For the fuel subtype CNG 138, the (LCA) GHG emission value in this embodiment, which is only one of very many possible, is 249.5 gC0 _2- equivalent / kWh _Hi BioMethane 13974.4 gC0 ₂ -equivalent / kWh _Hi , for SynMethan 141 11.9 gC0 ₂ -equivalent / kWh _Hi and for methane ^ZeroEmission 142 0.0 gC0 ₂ --equivalent / kWh _H i. Accordingly, the GHG emission amount 167 of CNG 138 fuel subtype was exactly 634.359 kWh _Hi x 249.5 gC0 ₂ -eq / kWh _Hi = 158.272.571 gC0 ₂ -eq. The GHG emission level 168 of the fuel subspecies BioMethan 139 was exactly 320.053 kWh _Hi x 74.4 gC0 ₂ -eq / kWh _Hi = 23,811,943 gC0 ₂ -eq. The THG emission level 169 of the fuel sub-type SynMethan 141 was 0.000 kWh _Hi x 11.9 gC0 ₂ -eq / kWh _Hi = 0.000 gC0 ₂ -eq and the emission of ^{greenhouse gases} 171 of the fuel sub-type methane ^ZeroEmission 142 was exactly 161.359 kWh _Hi x 0.0 gC0 ₂ -eq / kWh _Hi = 0.000 gC0 ₂ -eq. For the CNG mode, this results in a total emission of 165 GHGs totaling 182,084,514 gC0 ₂ -eq. For the fuel subspecies normal gasoline 144, the (LCA) GHG emission value in this embodiment, which is only one of many possible ones, is 335.9 gC0 ₂ -equivalent / kWh _H i, for Super E5 145 325.6 gC0 ₂ -Equivalent / kWh _Hi , for Super E10 145 318.8 gC0 ₂ -equivalent / kWh _Hi and for Super V-Power 147 335.9 gC0 ₂ -equivalent / kWh _H i. Accordingly, the GHG emission amount 172 of the fuel subspecies normal gasoline 144 was exactly 0.000 kWh _Hi x 335.9 gC0 ₂ -eq / kWh _Hi = 0.000 gC0 ₂ -eq. The THG emission quantity 173 of the fuel sub-type Super E5 145 was exactly 56.030 kWh _Hi x 325.6 gC0 ₂ -eq / kWh _Hi = 18,243,368 gC0 ₂ -eq. The THG emission quantity 174 of the fuel sub-type Super E10 146 was 53.430 kWh _Hi x 318.8 gC0 ₂ -eq / kWh _Hi = 17.033.484 gC0 ₂ -eq and the THG emission quantity 175 of the fuel sub-type Super V-Power 147 was exactly 0.000 kWh _H ix 335.9 gC0 ₂ -eq / kWh _Hi = 0.000 gC0 ₂ -eq. For the gasoline mode, this results in a total emission of 166 GHGs totaling 35,276,852 gC0 ₂ -eq. The total GHG emission quantity 164 is 166 of 35,276,852 gC0 ₂ -eq and the (LCA) GHG emission 165 (182,084) produced in CNG mode by addition of the (LCA) GHG emission produced in gasoline mode , 514 gC0 ₂ -eq a total of 217,361,366 gC0 ₂ -eq.

The average route specific kilometer (LCA) GHG quota 176 is calculated by dividing the (LCA) GHG emission amount 164 by the total distance 134, which is 217.361 kgC0 ₂ / 1.595 km = 136.3 gC0 ₂ / km results. The route-specific (LCA) GHG 177 in the CNG mode was exactly 182,084 kgC0 ₂ (GHG emissions 165) divided by 1,446 km (135 km traveled in CNG mode) = 125.9 gC0 in the April reporting month exemplified ₂ / km.

The fuel sub-type "CNG" 138 has a route-specific (LCA) GHG quota of 192.6 gC0 ₂ / km, which is calculated by multiplying the average energy input of CNG mode 162, which is 0.772 kWh _H i / km (see above) and the energy-specific GHG emission quota associated with the use of CNG amount to 249.5 gC0 ₂ -eq / kWh _H i (see above) Route-specific (LCA) GHG quota of 57.4 gC0 ₂ / km. This value is calculated by multiplying the average energy input of CNG mode 162, which is 0.772 kWh _H i / km (see above), and the energy-specific GHG emission quota associated with the use of BioMethan, 74.4 gC0 ₂ -eq / kWh _H i (see _above ). The Methane ^ZeroEmission fuel ^substandard 142 has a route-specific (LCA) GHG quota of 0.0 gC0 ₂ / km, which is calculated by multiplying by the average energy input of CNG mode 162, the 0.772 _H i kWh / km is (so) and the energy-specific GHG emission rate associated with the use of methane ^ZeroEmisslon from 0.0 GC0 ₂ eq / kWh _H i (see above).

The route-specific (LCA) GHG 178 obtained in gasoline mode was exactly 35,277 kgC0 ₂ (GHG emissions 166) divided by 149 km (136 driving distance in gasoline mode) = 236 in the April reporting month as an example. 8 gC0 ₂ / km. The fuel sub-type "Super E5" 145 has a route-specific (LCA) GHG quota of 239.3 gC0 ₂ / km, which is calculated by multiplying the average energy input of Gasoline Mode 163, which is 0.735 kWh _H i / km (see above) and the energy-specific GHG emission quota associated with the use of Super E5 is 325.6 gC0 ₂ -eq / kWh _H i (see above) On the fuel sub-type "Super E10" 146 In this case, a route-specific (LCA) GHG quota of 234.3 gC0 ₂ / km is omitted. This value is calculated by multiplying the average energy input of gasoline mode 163, which is 0.735 kWh _H i / km (see above), and the energy-specific GHG emission quota associated with the use of Super E10, 318.8 gC0 ₂ -eq / kWh _H i (see _above ). As the fuel subtypes "Regular Gasoline" 144 and "Super V-Power" 147 were not used during the reporting period, no GHG emission quotas are calculated for them. The reference emission quota 188 results from the theoretical use of only the reference fuel, which is normal gasoline in the embodiment shown here. Regular petrol according to fuel database 31 has an energy-specific LCA-GHG emission quota of 335.9 gC0 ₂ -eq / kWh _H i (see above). For a total energy input 148 of 1,225.2 kWh _H i, the total theoretical emissions are 335.9 gC0 ₂ -eq / kWh _Hi x 1,225.2 kWh _Hi = 411,544,680 gC0 ₂ -eq. This total emissions divided by the total distance 134 gives the reference emission rate 188 of 258 gC0 ₂ / km. If one subtracts the determined actual LCA-THG emission quota 176 (136 gC0 ₂ / km) from this reference value 188, the absolute GHG reduction performance 189 results, which in this exemplary embodiment amounts to 122 gC0 ₂ / km. If one sets this GHG reduction performance 189 in relation to the reference emission quota 188, one obtains the relative GHG reduction performance 191, which reaches 47.3% here.

The fuel consumption 192, 193 identified by the manufacturer for bivalent CNG vehicle 1 in type approval and officially named fuel consumption was CNG mode with 4.6 kg CNG in this embodiment and 6.8 liters per liter with gasoline mode 100 km accepted. Translated into the corresponding energy input, the known energy content for CNG (see above) for the CNG mode results in an official energy input 194 of 61.7 kWh _H i per 100 km and for the Benin mode an official energy input 195 of 58.8 kWh _H i per 100 km. Based on 100 km, the calculated actual energy input amounts to 162, 163 but 77.2 kWh _H i and 73.5 kWh _H |. For the CNG mode this results in an absolute deviation 198 of +15.5 kWh _H i / 100 km and for the petrol mode an absolute deviation 201 of +14.7 kWh _H i / 100 km. Relative to the official statements, there are relative percentage deviations 199, 202 of 25% each. The actual fuel consumption resulting from the everyday use of the bivalent CNG vehicle 1 is thus 25% higher than indicated by the manufacturer - for whatever reason.

The (stoichiometric) GHG emissions 203, 204 determined by the manufacturer for the bivalent CNG vehicle 1 at the type approval and officially named were in this embodiment for the CNG mode with 127 gC0 ₂ / km and for the gasoline mode with 160 gC0 ₂ / km assumed. For the CNG mode, the emission value of 127 gC0 ₂ / km results from the official fuel consumption 192, which was assumed to be 4.6 kg CNG / 100 km. The combustion of CNG, which usually consists of> 90% methane (CH ₄ ), takes place in the internal combustion engine ideally according to the formula CH ₄ + 20 ₂ >> 2H ₂ 0 + C0 ₂ . Carbon (C) has the molecular mass 12 and atomic hydrogen (H) the atomic mass 1, CH ₄ thus the molecular mass 16. Oxygen has the molecular mass 16 and C0 ₂ thus the molecular mass 44. When burned of methane (CH ₄ ) thus produces 2.75 times the C0 ₂ mass per employed CH ₄ mass (44/16 = 2.750). At the official fuel consumption 192 of 4.6 kg CNG / 100 km, which consists almost entirely of CH ₄ , this results in 4.6 kg x 2.75 = 12.650 kg CO ₂ per 100 km. Based on one kilometer, this results in an official stoichiometric GHG emission value 203 of 126.5 gC0 ₂ / km at a fuel consumption of 4.6 kg CNG / 100 km.

The calculation of the stoichiometric GHG emission assumes that one liter of gasoline consists of 639.4 g of carbon. Carbon (C) has the molecular mass 12 and C0 _2, the molecular mass 44. When burning 1 liter of regular gasoline in the internal combustion engine of the bivalent CNG vehicle 1 is produced as a THG emission so that 3.667 times the carbon input, ie 639.4 gC x 3.667 = 2.344.5 gC0 ₂ . At an official fuel consumption 193 of 6.8 liters per 100 km, a stoichiometric C0 ₂ emission of 6.8 x 2.344.5 = 15,942.52 gC0 ₂ , based on a kilometer covered by gasoline, is the official stoichiometric C0 ₂ -Emission rate 204 thus 159.4 gC0 ₂ / km. Based on one kilometer, the calculated actual LCA-GHG emission quotas are 177, 178 but 125.9 gC0 ₂ / km in CNG mode and 236.8 gC0 ₂ / km in gasoline mode. For the CNG mode this results in an absolute deviation 205 of -0.6 gC0 ₂ / km and for the gasoline mode an absolute deviation 206 of +77.4 gC0 ₂ / km. Relative to the official statements, relative percentage deviations of 207, 208 result from -0.5% and + 48.6%, respectively. The actual GHG emission resulting from everyday use of the bivalent CNG vehicle 1 is met in CNG mode, but significantly exceeded in gasoline mode. This essentially has its reason in the different view. While the stoichiometric consideration only examines the processes on the exhaust, the life cycle analysis goes far beyond (see above).

In a departure from the exemplary embodiment of FIG. 25, the following also applies to the NO _x emissions 209, 211, 216, 217, 218, 219, 221, 222, 223, 224, 225, 226 and the particulate matter emissions 227, 228, 229 , 231, 232, 233, 234, 235, 236, 237, 238, 239 of the CNG vehicle 1, respectively. With regard to NO _x emissions, it is assumed that the corresponding measurements in daily operation in CNG mode have a NO _x emission quota 218 of 39 mg N0 ₂ -eq / km and in gasoline mode a NO _x emission quota 219 of 59 mg N0 ₂ And these quota values have arrived at the back end 22 as part of the data packet transmitted from the front end 7 to the back end 22. By multiplying the route-specific NO _x emission quota values 218, 219 with the corresponding driving distances 135 and 136, the NO _x emission amounts 211 and 216 result. The addition of the NO _x emission amounts 211 and 216 gives the NO _x total amount 209 Division of total NO _x 209 through total distance 134 results in the average NO _x emissions quota 217. As NO _x emission quotas 221, 222 officially stated by the manufacturer, 30 mg NO ₂ -eq / km were assumed for the CNG mode and 50 mg N0 ₂ -eq / km for petrol mode. Absolute deviations 223, 224 of 9 mg N0 ₂ -eq / km thus result for the actual NOx emission quota values 218, 219 determined, which correspond to relative deviations 225, 226 of + 30% and + 18%, respectively, based on the official data ,

With regard to particulate emissions, it is assumed that the corresponding measurements in daily operation in CNG mode have resulted in a particulate emission quota 232 of 2,000 mg PM / km and in gasoline mode a particulate matter emission quota 233 of 4,000 mg PM / km and these quota values have arrived at the back-end 22 as part of the transmitted from the front-end 7 back-end 22 data packet. Multiplying the route-specific particulate emission quota values 232, 233 with the corresponding routes 135 and 136 results in the particulate matter emission levels 228 and 229. The addition of the particulate matter emission levels 228 and 229 results in the particulate matter total 227. The division of particulate matter Total distance 227 through the total distance 134 results in the average particulate matter emission rate 231. As the manufacturer's officially stated particulate matter emission values 234, 235, 1.500 mg PM / km were assumed for the CNG mode and 3.500 mg PM / km for the gasoline mode. Absolute deviations 236, 237 of 0.500 mg PM / km thus result for the actually determined particulate emission emission values 232, 233, which relative to the official data shows relative deviations 238, 239 of + 33.3% and + 14.3%, respectively. equivalent.

Since it will be obvious to one of ordinary skill in the art having the benefit of this invention to calculate the above values, a description of modified approaches for determining various fuel consumption, energy input, and emissions levels will be omitted. Incidentally, the general procedure for determining these values results from the statements made above on FIGURES 25, 26 and 27. The descriptions above refer to the figures and representations given. These illustrate only certain exemplary embodiments of the invention. Those skilled in the art will appreciate that other embodiments of the inventive method and system are possible and that modifications and changes of the invention are possible without departing from the spirit, and the scope of the invention. The above descriptions and examples and illustrations are therefore not intended to limit or limit the invention.

It should be noted that the figures and drawings of the various embodiments have been simplified to highlight the elements that are relevant to a clear understanding of the invention. This involves omitting other elements. Those of ordinary skill in the art will recognize that it would be desirable to also describe these omitted elements. However, since these elements are known in the art and since they do not significantly improve the understanding of the invention, a description of these elements is omitted.

It will be apparent and obvious to one of ordinary skill in the art upon appreciation of the invention that the above-listed embodiments, or portions thereof, can be implemented in many different software, firmware, and hardware variations and variations. The above-mentioned embodiments and functions therefore do not relate to specific software, software codes or special hardware components. The waiver of such naming is possible and permissible, as the average person skilled in the art, with the disclosures and descriptions herein, will be able to design software and hardware components that are suitable, the method of the invention, and with reasonable effort and without unnecessary experimentation / or implement the inventive system or its embodiments as well as obvious variants of the embodiments in useful solutions.

Accordingly, software implementing the inventive method that causes programmable devices to perform process steps may be stored in any storage medium, for example, in the persistent memory of a computer system, on an optical disk, on magnetic tape, or on a magnetic disk. Some of the method steps may already be implemented in the software during the manufacture of the electronic components, programmed and loaded on these memories or afterwards with a medium that can be read by computers. These media may include any type and variant of the storage media listed above, as well as an optical, electrical or electromagnetic carrier wave that is manipulated to convey execution instructions that can be read, demodulated, decrypted and executed by computers ,

Work instructions for electronically performing steps or substeps of the method according to the invention or one of its variants can be stored on a computer-readable medium. Computer readable media may e.g. Memory devices such as floppy disks, read-only CDs, read / write CDs, optical disks, hard disks and solid state disks include. The storage of work instructions on these media may be physical, virtual, permanent, temporary, semi-permanent, and / or semi-temporary. The computer readable medium may include one or more signals transmitted on one or more carrier waves.

A "computer" or "computer system" as understood in this disclosure may include a variety of wireless or wired mainframes, host computers, microcomputers, minicomputers, laptops, PDAs, wireless e-mail devices (eg, Blackberry ), Mobile Telephones, pagers, processors or any other programmable device capable of transmitting and receiving data over a network. Computers may include memories that are capable of storing certain software applications for acquiring, processing and transmitting data. These can be internal or external storage. The memories may include any means suitable for storing software including hard disks, optical disks, floppy disks, ROM (Read Only Memory), random access memory (RAM), programmable ROM (PROM), EEPROM (Electrically Erasable PROM ) and other computer-readable media.

In certain embodiments and further developments of the disclosed invention, to perform one or more functions, one component may be replaced with a plurality of components, and multiple components may be substituted by a single component. Except where such substitution is impractical for the particular embodiment, such substitutions are considered to be within the scope of the invention.

List of reference numbers vehicle

Tank level sensor of the vehicle 1

Rotation sensor of the vehicle 1

Odometer of the vehicle 1

OBD2 bus / OBD2 system of a vehicle 1

OBD2 nut socket of a vehicle equipped with an OBD2 system 1

Front End

Smartphone

OBD2 father connector of the front-end 7

First simple variant of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions in everyday operation of a vehicle

GPS module with GPS antenna

Clock of the front-end 7

Battery and power management subsystem of the front-end 7

WiFi / WLAN front-end 7 interface (and as smartphone's 14 ^' 8)

Mobile interface (modem) of the front-end 7 (and as 15 ^'of the smartphone 8) for wireless communication with a mobile network (eg GSM, MOBITEX, DATA TAC, ORBCOMM, CDMA, UMTS, HSDPA, LTE, LTE). Advanced, GPRS, EDGE, TD-SCDMA, etc.) Mobile card slot / front-end SIM card 7 (and as 16 ^'of the smartphone 8) short-range transceiver module (Short Range Device SRD) of the front End 7 (and as 17 ^'of the smartphone 8), preferably a Bluetooth chip or a Bluetooth interface

Internet access

Internet

Mobile mast as access to mobile network 21

Mobile network

Back-End

Host system of back-end 22

Host server of the host system 23

Gateway of the host system 23

Web server of the host system 23

CPU / microprocessor of the host server 24

Memory of the host server 24

Program memory of the host server 24

Vehicle database / file of the host server 24

Fuel database / file of the host server 24 Gas station database / file of the host server 24

GPS system with variety of GPS satellites

monthly report

Subsystem of the vehicle 1, which is suitable to determine GPS coordinates and pass it on to the OBD2 system of the vehicle

Subsystem / module of the smartphone 8, which is capable of GPS coordinates to determine and forward to the front-end 7 or the back-end 22

Vehicle-external device with GPS module 11, which is capable of GPS coordinates to determine and forward to the front-end 7 or the back-end 22

Socket capable of retrieving / reading out the vehicle-specific data stored in the front-end 7 or a version thereof from the front-end 7 and transmitting it to a device 39 (eg to a PC connected to the Internet or the like). external device (eg, a PC connected to the Internet, an external vehicle diagnostic system, a laptop, a tablet, a smartphone, or the like) capable of retrieving vehicle-specific data or a version thereof from the front-end 7 / read and forward to the back-end 22

Second embodiment variant of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions in the everyday operation of a vehicle

Electronic Control Module (ECM) of the vehicle 1

Power Control Module (PCM) of the vehicle 1

Electronic Control Unit (ECU)

Housing of the OBD2 adapter

Communication interface (gateway) of the OBD2 adapter

Communication protocol SAE-J1850-VPW

SAE-J1850-VPWM protocol for communication over d. OBD2 interface d. Vehicle 1 ISO 9141-2 protocol for communication via the OBD2 interface of the vehicle 1, KWP 2000 protocol for communication via the OBD2 interface of the vehicle 1 CAN protocol for communication via the OBD2 interface of the vehicle 1,

CPU or microprocessor of the front-end 7

GPS antenna of the GPS module 11

Memory module of the front-end 7

Program memory of the memory module 53

Data memory of the memory module 53

General interface of the front-end 7 for the connection of peripheral devices, preferably an RS 232 interface with appropriate driver software

SAE-J1587 protocol for communication via the OBD interface of a truck Antenna for the mobile modem 15

SAE-J1708 protocol for communication via the OBD interface of a lorry Third embodiment variant of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions in everyday operation of a vehicle

Switching device capable of receiving data from the front-end via a suitable interface and using an appropriate protocol (cable, Bluetooth, WiFi / WLAN or the like) and this data or a version thereof with and without caching and with and without supplementation Further data (such as GPS data, date and / or time) via an existing communication network (Internet, telephone network, mobile network, cable network or the like) forward to the back-end

"Registration of vehicle 1, user and front-end 7 at the back-end 22" "Subscription: Completion completed?"

Execution "front end 7 with original data collection scheme is plugged into OBD2 nut socket 6 of the vehicle 1"

Abiaufschritt "Verification and approval of the front-end 7 in the system, if necessary, including Smartphone 8"

Execution "Query: Verification completed?"

Step "Front-end 7 picks up communication with OBD2 system 5 of vehicle 1 and checks if any of communication protocols 46-50 is functioning"

Step "Query: Has the host computer 43 of the OBD2 system 5 of the vehicle 1 responded?"

Sequence "Data monitoring, data selection and data storage by the front-end 7 according to a predetermined data collection scheme"

Fourth embodiment variant of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions during everyday operation of a vehicle

"Query: Is there any reason for the (direct or indirect) transmission of the current raw data packet to back-end 22?"

Sequence "Selection of the communication path according to a given communication scheme"

Abeiufschritt "Query: Is the receiver a switch 61 (a smartphone 8)?"

Follow-up "Direct data transmission via communication network (Internet, mobile network) to the back-end 22"

Abiaufschritt "Indirect data transfer first to switching device 61 (Smartphone 8)"

Abeiufschritt "Query: data transmission from front-end 7 to switch 61 (Smartphone 8) successful?"

Abiufschritt "data transmission from switching device 61 (Smartphone 8) via communication network (Internet, mobile network) to the back-end 22"

Execution: "Data transfer from front-end 7 to back-end 22 successful?" Execution step "Query: Data transfer from switch 61 (smartphone 8) to back-end 22 successful?" 80 Fifth version of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions in everyday use of a vehicle

81 "Interim storage of the transmitted raw data packet in the backend 22"

82 Step "Query: Is there a reason for data analysis?"

83 Execution "Calculation of the raw data by algorithm, supplementing the data records with the result data and storage of the completed data records in the vehicle file / database 30"

84 Step by Step "Data provisioning in web server 26"

85 navigation device

86 peripheral device

87 GPS Module in Peripheral Device 86 or Navigation Device 85

88 GPS antenna of the GPS module 87

89 Not used

90 Sixth variant of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions in everyday use of a vehicle

91 "Front-end 3" step on the OBD2 socket of vehicle 1 and reads the data supplied by OBD2 system 5 "

92 Step "Query: 15 seconds expired?"

93 Execution "Query: Speed = 0?"

94 Step "Query: Tank level rises?"

95 AbiStschritt "start of refueling: storage tank level + odometer reading + GPS coordinates + date + time"

96 "Poll: 10 seconds expired?"

97 Abiaufschritt "Inquiry: Is tank level still rising?"

98 Carrying out the process "End of refueling: tank level storage + odometer reading + GPS coordinates + date + time"

99 Execution "Transmission of the 2 data records to the back-end 22"

Seventh variant of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions in everyday use of a vehicle

101 Header of the raw data extract 150

102 data records in the data area of the raw data extract 150

103 Data field "vehicle identification number" in the data record 102

104 Data field "check digit for vehicle identification number 103" in the data record 102

105 Data field "Fuel type or energy source It. Motor vehicle license" in the data record 102

106 Data field "Identification number of the front-end 7" in the data record 102

107 Data field "Software release, with which the front-end 7 has generated the data record" in the data record 102

108 Data field "data set number of the front-end 7" in the data record 102 109 Data field "Reason for data record generation" in data record 102

110 Eighth variant of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions resulting from the daily operation of a vehicle, consisting of 4 sub-variants

111 Data field "Date created at the time of generation of the data record" in data record 102

112 Data field "Timestamp created at the time of generation of the data record" in the data record 102

113 Data field "Tank level of tank 1 with fuel main type 113 ^' at the time of generation of the data record" in data record 102

114 data field "Tank level of the tank 2 with fuel main type 114 ^' at the time of generation of the record" in the record 102

115 Data field "GPS length coordinate of the vehicle 1 at the time of generation of the data record" in the data record 102

116 Data field "GPS latitude coordinate of the vehicle 1 at the time of generation of the data record" in the data record 102

117 Data field "Odometer reading of the vehicle 1 at the time of generation of the data record" in the data record 102

118 Data field "Per day with the vehicle 1 traveled distance = daily kilometer" in the data set 102

119 Data field "The distance traveled by the vehicle 1 with the main fuel type 1 per day" in the data record 102

Ninth variant of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions resulting from the daily operation of a vehicle consisting of 4 sub-variants

121 Data field "The distance traveled by the vehicle 1 with the main fuel type 1 per day" in the data record 102

122 Data field "CNG quantity in kg / segment 121" or "CNG quantity in kg / refueling"

123 Data field "Gasoline quantity in liters / partial distance 121" or "Gasoline quantity in liters / refueling"

124 Data field "Energy input quantity in kWh _H i / partial distance 121" or "Energy quantity in kWh _H i / refueling" or "Energy quantity of the fuel residue"

125 Data field "Lifecycle emission rate relevant for segment 121" or "Lifecycle emission quota of tank content"

126 Data field "GHG emission quantity"

127 Data field "C0 ₂ emission in gC0 ₂ -equivalent per kilometer section 121"

128 "Gas station" data field (only filled with data for refueling data records)

129 User PC, connected to the Internet 19

130 Tenth variant of the system for determining the actual fuel consumption, energy inputs and greenhouse gas emissions resulting from the day-to-day operation of a vehicle, consisting of 4 sub-variants

131 Header of Report 180

132 Data area of the report 180 133 Period for which Report 180 is created

134 Total distance covered by vehicle 1 during the reporting period 133

135 Route share on the entire route 134 traveled by the vehicle 1 with the first fuel main mode (in the example of FIG. 27 in CNG mode)

136 Route share on the entire route 134, which has covered the vehicle 1 with the second fuel Hauptart (in the example of Figure 27 in gasoline mode)

137 Fuel consumption of the first main fuel type (CNG consumption in the example of FIG. 27)

138 CNG Consumption Share of First Fuel Home Type

139 BioMethan consumption share of the first main fuel type

140 Connection procedure of a front-end to the OBD2 nut socket of a vehicle 1 with connection result (fully connected front-end)

141 SynMethan consumption share of the first main fuel type

142 Methane ^{ZeroEmission Consumption share} of the first main fuel type

143 Fuel consumption of the second main fuel type (in the example of FIG. 27, the petrol consumption)

144 Regular gasoline consumption share of the second main fuel type

145 Super E5 Consumption Share of the Second Major Fuel Type

146 Super E10 consumption rate of the second main fuel type

147 Super V-Power consumption share of the second main fuel type

148 Total amount of energy used by the vehicle 1 on the route 134

149 Energy input amount attributable to the first main fuel type

150 Schematic diagram illustrating the sequence of the registration and the normal operation of a front-end 7 in the system according to the invention

151 Energy input used for fuel type "CNG"

152 Energy input amount attributable to the fuel sub-type "BioMethane"

153 Energy input amount attributable to the fuel subtype "SynMethan"

154 Energy input used for the fuel subtype "Methane ^ZeroEmission "

155 Energy input amount attributable to the second main fuel type

156 Energy input amount attributable to the fuel sub-type "regular gasoline"

157 Energy input amount attributable to the fuel sub-type "Super E5"

158 Energy input amount attributable to the fuel sub-type "Super E10"

159 Energy input amount attributable to the fuel sub-type "Super V-Power"

160 Excerpt from the raw data delivered by a front-end for a given vehicle

161 Average total energy used per total kilometer

162 energy use per kilometer based on the first main fuel type (in the example of FIG. 27 CNG)

163 energy use per kilometer based on the second main fuel type (in the example of FIG. 27 petrol) 164 Total (LCA) GHG emissions generated on route 134

165 Proportion of the emission quantity of the first main fuel type in the total emission quantity

166 Proportion of the emission quantity of the first main fuel type in the total emission quantity

167 Emissions share from CNG use

168 Emissions share from bio methane use

169 Emissions share from SynMethan usage

170 Simplified algorithm for determining actual fuel consumption, energy use and GHG emissions

171 Emissions ^share from use of methane ^ZeroEmisslon

172 Amount of emissions from the use of normal gasoline

173 Emissions share from using Super E5

174 Amount of emissions from use of Super E10

175 Emissions share from using Super V-Power

176 Average total emissions per total kilometer

177 Emissions quota relative to the kilometers traveled with the first main fuel type

178 Emissions quota based on the kilometers traveled with the second main fuel type

179 Emissions quota based on kilometers traveled with CNG

180 A report detailing the actual fuel consumption in everyday use of a vehicle, the corresponding energy input and the corresponding (LCA) GHG emissions

181 Emissions ratio based on kilometers traveled with BioMethan

182 Emissions ratio based on kilometers traveled with SynMethan

183 Emission ^quota based on kilometers traveled with methane ^ZeroEmisslon

184 Emissions quota based on the normal gasoline mileage

185 Emission ratio relative to the kilometers covered with Super E5

186 Emission ratio relative to the kilometers covered with the Super E10

187 Emission ratio related to the kilometers covered with Super V-Power

188 Reference emission ratio based on the total kilometers 134

189 Greenhouse gas reduction performance as emission quota per total kilometer 134

190 Process Recovery of refueling records

191 the greenhouse gas reduction performance as a percentage

192 Official fuel consumption per kilometer in CNG mode

193 Official fuel consumption per kilometer in gasoline mode

194 Official energy use per kilometer in CNG mode

195 Official energy use per kilometer in gasoline mode

196 Not forgiven 197 Not forgiven

198 Absolute difference between the official and actual energy use per kilometer in CNG mode

199 Relative percentage difference between official and actual energy use per kilometer in CNG mode

200 Design variant of an extract from the raw data supplied by a front-end

201 Absolute difference between the official and actual energy use per kilometer in gasoline mode

202 Relative percentage difference between official and actual energy use per kilometer in gasoline mode

203 Official GHG emissions per kilometer in CNG mode

204 Official GHG emissions per kilometer in gasoline mode

205 Absolute difference between the official and actual GHG emissions per kilometer in CNG mode

206 Absolute difference between the official and actual GHG emissions per kilometer in gasoline mode

207 Relative percentage difference between official and actual GHG emissions per kilometer in CNG mode

208 Relative percentage difference between official and actual GHG emissions per kilometer in gasoline mode

209 Absolute total NO _x emission amount incurred on the total travel distance 134

210 Not used

211 Absolute NO _x emission amount accumulated on the first fuel main route 135 (CNG mode)

212 Progress "Download the app" Know Your Footprint "on a Smartphone 8

213 Battery of the vehicle 1

214 Cable connection between front-end 7 and navigation device 85

215 Main fuel used by the vehicle 1

216 Absolute NO _x emission amount accumulated on the running distance 136 (gasoline mode) traveled by the second main fuel mode

217 Average NO _x emissions quota relative to the total route 134

218 NO _x emission quota based on the distance traveled with the first main fuel type 135 (CNG mode)

219 NO _x emission quota based on the distance covered by the second main fuel type 136 (gasoline mode)

220 Not forgiven

221 Official NO _x quota based on one CNG kilometer

222 Official NO _x quota based on one gasoline kilometer

223 Absolute difference between the official NO _x quota 221 (CNG mode) and the determined NO _x emission quota 218 (CNG mode) 224 Absolute difference between the official NO _x quota 222 (gasoline mode) and the determined NO _x emission quota 219 (gasoline mode)

225 Relative, percentage difference between the official NO _x quota (CNG mode) and the determined NO _x emission quota (CNG mode)

226 Relative, percentage difference between the official NO _x quota (gasoline mode) and the determined NO _x emission quota (gasoline mode)

227 Total amount of particulate matter emitted on the total distance covered 134

228 Absolute particulate matter emission level accumulated on the first fuel main route 135 (CNG mode)

229 Absolute particulate emission level accumulated on the second fuel main route 136 (gasoline mode)

230 Not awarded

231 Average particulate matter emission quota based on the total route 134

232 Particulate matter emission quota based on the distance covered by the first main fuel type 135 (CNG mode)

233 Particulate matter emission quota based on the distance covered by the second main fuel type 136 (gasoline mode)

234 Official fine dust quota based on one CNG kilometer

235 Official fine dust quota related to one gasoline kilometer

236 Absolute difference between the official particulate matter quota 234 (CNG mode) and the calculated particulate emissions quota 232 (CNG mode)

237 Absolute difference between the official particulate matter quota 235 (gasoline mode) and the calculated particulate emissions quota 233 (gasoline mode)

238 Relative percentage difference between the official particulate matter quota (CNG mode) and the calculated particulate matter emission quota (CNG mode)

239 Relative, percentage difference between the official fine dust quota (gasoline mode) and the determined particulate matter emission quota (gasoline mode)

Claims

claims

1. A method for determining the actual fuel consumption, energy inputs and greenhouse gas emissions (GHG emissions) that occur in the daily operation of at least one road vehicle 1, in which

an electronic front-end 7 connected to and capable of receiving, reading and storing data from at least one electronic component of a road vehicle 1, vehicle-specific data related to that electronic component, or a version of that data directly or transmits indirectly to a back-end 22,

- The back-end 22 comprises at least one file or database with vehicle-specific data (vehicle file / database 30) and at least one file or database with fuel-specific data (fuel file / database 31) or at least temporarily associated with one or more components of a data link system comprising a vehicle file / database 30 and / or a fuel file / database 31,

- the back-end 22 receives and processes the vehicle-specific data, d a n d u r c h e c e n c e s, d a s s

is transmitted to the back-end 22 or is determined or calculated in the back-end 22, which distance a road vehicle 1 traveled;

is transmitted to the back-end 22 or determined or calculated in the back-end 22, which fuel types and / or types of power the road vehicle 1 has consumed on this route,

- transmitted to the back-end 22 or in the back-end 22 is determined or calculated, which fuel and / or electricity quantities has consumed the road vehicle 1 on this route.

2. The method of claim 1, wherein the fuel-specific (including power-type-specific) data of the fuel file / database 31 data on the greenhouse gas emission of at least one fuel or at least one type of current include and in the Back end 22 from the traveled distance of the road vehicle 1, the consumed on this route fuel or electricity, the fuel and / or electricity consumed on this route and the fuel / power type-specific GHG emissions is calculated, which GHG Emission amounts (masses, volumes) the road vehicle 1 has emitted on the traveled route in the earth's atmosphere.

3. Method according to one of claims 1 and 2, in which the transmission of the vehicle-specific data obtained from the electronic component of the road vehicle 1 or the version of this data to a back-end 22 occurs wirelessly via a communication network and / or the back-end End 22 receives and processes the vehicle-specific data from a communication network.

1

4. The method according to any one of claims 1 to 3, wherein the traveled by the road vehicle 1 route includes the route that the road vehicle 1 has traveled between two refueling or between several refueling, preferably partial distances that were covered between two refueling and particularly preferably individual Trips, whereby the single trip is defined as the distance traveled between the start and stop of the engine.

5. The method according to any one of claims 1 to 4, wherein the analysis and / or calculation results produced by the back-end 22 of at least one user can be used, preferably from a selection of the following uses: for individual users and / or companies visible via a website; for institutions and / or companies visible and / or retrievable from the back-end 22; for at least one software application retrievable from the back end 22, from a web server or from an external database; transferable to a computer or a computer system; Transmitted to an electronic communication terminal; transferable to an internet computer; transferable to a data link system; transmitted by e-mail to at least one user; retrievable storage in a back-end internal file or database; retrievable storage in a back-end external file or database; Use in any other way.

6. The method according to any one of claims 2 to 5, wherein the fuel / electricity type-specific GHG emission value from fuel-specific data and other data is determined, preferably using one or more algorithms.

7. The method according to any one of claims 1 to 6, wherein the fuel-specific data are differentiated by fuel main and fuel sub-types.

8. The method of claim 7, wherein the at least one main fuel type comprises a selection from the fuel groups of the diesel fuels, the gasoline fuels, the kerosene fuels, the natural gas (CNG) fuels, the LNG fuels, the LPG Fuels, hydrogen gases, nitrous gases, methanols, various types of electricity, a power mix and other fuel groups

and or

in which the at least one fuel subspecies comprises a selection from the following fuel sub-types: diesel fuels of different origin, biodiesel types of different origin, various mixtures of diesel fuels and biodiesel types, gasolines of different origin, bioethanols of different origin, various mixtures of gasoline and bioethanols , CNG of different origin, (bio) methane of different origin, various mixtures of CNG and (bio) methane, LNG of different origin, LBM (Liquefied BioMethane) of different origin, various mixtures of LNG and LBM, LPG of different origin, synthetic methane (SynMethane) different origin, various mixtures of SynMethane of different origin, various mixtures of SynMethan and CNG, various mixtures of SynMethan and BioMethan, hydrogen from different sources, various mixtures of hydrogen from different sources, electricity of different origin, various mixtures of electricity of different origin, other fuels of different origin and other fuel subspecies.

2

9. A method according to any one of claims 2 to 8, wherein life cycle greenhouse gas emissions (LCA GHG emissions) determined by life cycle analysis (LCA) are preferably total LCA GHG emissions of the greenhouse gas emissions Include road vehicle 1 and particularly preferably the LCA-GHG emissions of the road vehicle 1 are divided and / or identified by gas types.

10. The method according to any one of claims 1 to 9, wherein the transmitted to the back-end 22 vehicle-specific data include odometer readings or traveled distances or in the back-end 22, the distances traveled from other vehicle-specific data are determined.

11. The method according to any one of claims 1 to 10, wherein the distance traveled and / or the amount of fuel or electricity consumed is calculated by the front-end 7 or by a device which is connected to the front-end 7.

12. The method according to any one of claims 1 to 11, wherein the vehicle-specific data transmitted to the back-end 22 data on tank levels, to states of charge of the vehicle batteries or to quantitative fuel consumption (including power consumption) include or in the back-end 22 the Fuel and / or power consumption values, preferably the route specific fuel and / or power consumption values from other vehicle-specific data will be determined.

13. Method according to one of claims 1 to 12, in which the fuel-specific data of the fuel file / database 31 comprise data on the energy content or calorific value of at least one fuel, or the fuel-specific energy content or calorific value from other fuels. specific data and / or additional data.

14. The method according to claim 1, wherein the fuel file / database 31 for at least one fuel type or at least one flow type comprises technical data for the fuel-specific GHG emission, preferably data for the fuel-specific LCA. GHG emission, particularly preferably data on energy-specific (energy-related) GHG emission and in particular data on energy-specific LCA-GHG emission.

15. The method according to any one of claims 1 to 14, wherein the reference to the fuel-specific energy contents or calorific values of the route-specific quantitative fuel consumption is converted into a route-specific amount of energy use.

16. The method according to at least one of claims 14 and 15, in which the GHG emission, preferably the LCA-GHG emission, from the route-specific use of energy and the energy-specific (LCA) GHG emission is calculated.

17. Method according to one of claims 1 to 16, in which the determined route-specific values of the road vehicle 1 are converted into other vehicle and / or route-specific quota values, preferably into common vehicle and / or route-specific quota values (eg in fuel consumption / distance, energy consumption / distance traveled, fuel consumption / 100 km, energy consumption / km, energy input (quantity) per year,

3 LCA-THG emission (s) in gC0 _2- eq / km, C0 ₂ eq emission per month, C0 ₂ emissions per year and the like).

18. The method according to any one of claims 1 to 17, wherein the front-end 7 consists of one of the following devices and this device is adapted to receive vehicle-specific operating data via a suitable interface: OBD interface module, OBD memory module, OBD Adapter, OBD2 adapter, client computer device, PC, laptop, PDA, telephone, internet enabled telephone, wireless communication, WiFi enabled devices, UWB hub, smartphone, navigation system, computer system, peripheral connection module, display , other front-end device.

19. The method according to any one of claims 1 to 18, wherein the electronic component with which the front end 7 is connected in the road vehicle 1, consists of a selection of the following components: Engine Control Unit (ECU), Electronic Control Unit (Electronic Control Unit ECU), Electronic Control Module (ECM), Power Control Module (PCM), OBD Compliant Vehicle Internal Computer System, Shared Standardized Electronic Bus, On-Board Computer Network, OBD2 bus, Proprietary or manufacturer-specific electronic system, microcontroller, pressure sensor, electrical switch, mechanical switch, magnetic switch, pneumatic switch, optical sensor, light sensor / photocell, sound sensor, sonar system, radar system, proximity sensor, infrared Sensor, temperature sensor, gas sensor, particle sensor, balance, voltage sensor, amperage sensor.

20. The method of claim 1, wherein the parts of the back-end comprise a selection of the following devices: host computer, host computer system, gateway computer, data reception / transmission module, microprocessor , CPU, data analysis module, data processing module, data storage (module), web server.

21. The method of claim 20, wherein the functions of the parts of the back-end 22 are perceived by one or more devices.

22. The method according to any one of claims 1 to 21, wherein the front-end 7 transmits the vehicle-specific data or a version thereof via a connection to a switching device 61, this switching device 61 receives this data from the front-end 7 and this data or a Version of it via a communication network to the back-end 22 forwards.

23. The method of claim 22, wherein the switch 61 is a selection of: mobile user communications terminal, navigation device, telephone, laptop, PC, electronic camera, mobile vehicle communication device, mobile tower with corresponding receiving and transmitting devices, WiFi router, Smartphone, tablet, PDA, communication device with Internet access, communication terminal with Internet access, other interactive access to a communication network or the like.

4

24. The method of claim 22 or 23, wherein the connection between the front-end 7 and the switching device 61 is wireless, and preferably consists of a Bluetooth ^® connection or an 802.11b connection.

25. The method of claim 22 or 23, wherein the connection between the front-end 7 and the switching device 61 is made via plug contacts and / or cables, and preferably is a USB connection.

26. The method according to any one of claims 22 to 25, wherein the switching means 61, the data received from the front-end 7, a version thereof and / or additional data that has not been transmitted from the front-end 7, via a selection of the following communication networks to the back-end 22 transmits: mobile network, terrestrial mobile network, satellite-based mobile network, Internet, fixed telephone network, cable network, data network, other communication network.

27. The method according to any one of claims 1 to 26, wherein the road vehicle 1 receives a unique identification, preferably a numeric or alphanumeric identification number, and / or in which the front-end 7 and / or the switching device 61 associated with the road vehicle 1 are.

28. The method according to any one of claims 1 to 27, wherein the front-end 7 obtains data from a vehicle diagnostic system of a road vehicle 1 or from a part of a vehicle diagnostic system, preferably from the statutory OBD system of Road vehicle 1, particularly preferably from the OBD2 system 5 of the road vehicle 1 and in particular from a successor system of the OBD2 system. 5

29. The method according to any one of claims 1 to 28, wherein the front-end 7 relates the vehicle-specific data via an assembly line diagnostic link (ALDL) plug contact, via an OBD plug-in contact or via an SAE plug contact, preferably via an OBD2 - Plug contact, particularly preferably via a SAE J1962 plug contact and in particular via a successor model of the OBD2 plug contact.

30. The method according to any one of claims 1 to 29, wherein the front-end 7 for reading the vehicle-specific data from the at least one electronic component of the road vehicle 1 uses a selection of the following communication protocols: SAE-J1850-VPW (Ford ), SAE-J1850-VPWM (GM), ISO, ISO 9141-2 (Toyota & most European manufacturers), KWP, KWP 2000 (some Hyundai & Mercedes models), CAN (Next-Generation Vehicles, from 2004) , a successor protocol to one of these protocols.

31. The method according to any one of claims 1 to 30, wherein the parts of the front-end 7 include a selection of the following components: housing, OBD connector, OBD interface, gateway module with driver, signal conditioner, microprocessor (eg A M7, ARM9), CPU, Program Memory, Data Memory, Clock, Bluetooth Antenna, Bluetooth Transmitter Module, Bluetooth Receiver Module, Mobile Antenna, Mobile Transceiver Module, SIM Card Slot, SIM Card, WiFi Interface, interface for memory expansion, memory expansion, microcontroller, antenna for GPS signals, evaluation unit for GPS signals, internal battery or

5 Battery, electronics for regulating and / or controlling the power supply, serial interface for peripheral devices (for example, second modem, wireless transmit / receive unit, Blue- tooth ^® send / receive unit, 802.11b transmission / reception Unit), cables or printed circuit board sections.

32. The method according to any one of claims 1 to 31, wherein the GPS signals from satellites of the US NAVSTAR-G PS system, the Russian GLONASS system, the European GA-LILEO system and / or the Chinese BEIDOU system received, converted into GPS coordinates and added to the vehicle-specific data, preferably from a component of the road vehicle 1, particularly preferably from the front end 7 and in particular from the switching device 61.

33. Method according to one of claims 1 to 32, which includes the transmission of global positioning data to the back-end 22 and in which this GPS data is preferably determined during the refueling of a road vehicle 1 and to the back-end 22 are transmitted.

34. The method according to any one of claims 1 to 33, wherein the front-end 7 and / or the switching device 61 provided a data acquisition with an electronic time and or date stamp.

35. The method according to any of claims 1 to 34, wherein the fuel file / database 31 is adapted to receive, store and retrieve properties, features, indications, values or data, preferably LCA-C0 ₂ emission values , particularly preferably the LCA-C0 ₂ emission values of a selection from the fuel main types gasoline, diesel, kerosene, CNG, LNG, LPG, methanol, electricity, hydrogen, nitrous oxide and in particular the LCA-C0 ₂ emission values of a selection from the fuel Subtrades Diesel of different origin, BioDiesel of different origin, various mixtures of diesel and biodiesel, gasoline of different origin, bioethanol of different origin, various mixtures of gasoline and bioethanol, kerosene of different origin, BioKerosin different origin, various mixtures of kerosene and BioKerosin, CNG of different origin , BioMethane of different origin, various mixtures of CNG and B ioMethane, LNG of different origin, LBM (Liquefied BioMethane) of different origin, various mixtures of LNG and LBM, LPG of different origin, nitrous oxide of different origin, synthetic methane (SynMethan) of different origin, various mixtures of SynMethane of different origin, hydrogen of different origin, various mixtures from hydrogen of different origin, electricity of different origin, various mixtures of electricity of different origin, other fuels of different origin and the like).

36. The method according to claim 1, wherein at least one of the following technical values is calculated, stored and / or exported via a suitable data interface in the back-end from the transmitted vehicle-specific data: the emission of (LCA-) C0 ₂ -equivalent in absolute value, the (LCA-) C0 ₂ -eq emission amount per trip, the (LCA-) C0 ₂ -eq emission amount per period (day, week, month, year, vehicle Service life, etc.), the (LCA) C0 ₂ eq emission

6 tankings, the emission of (LCA) C0 ₂ equivalents in a relative quota, the (LCA) C0 ₂ eq emissions per km of travel, the (LCA) C0 ₂ eq emissions per 100 km of travel, the (LCA) C0 ₂ eq emission quantity per kilogram (kilogram, ton, liter, gallon), the (LCA) C0 ₂ eq emission quantity per unit of energy (MJ, kWh), the emission of (LCA-) C0 ₂ Equivalents in other technical representations or values.

37. The method according to any one of claims 1 to 36, wherein the front-end 7 is an OBD2 adapter, preferably a successor model of the OBD2 adapter, more preferably an OBD2 adapter that wirelessly transmits the vehicle-specific data via a suitable air interface transmits to the switching device 61 or a communication network, and in particular a Golo adapter ("Remote Diagnosis In Car Telematic Device") of Launch Tech Co or a comparable adapter this or another manufacturer.

38. The method according to any one of claims 1 to 37, wherein the functions of the front-end 7 and the switching device 61 are wholly or partly integrated in a device.

39. The method according to any one of claims 1 to 38, wherein the functions of the switching device 61 and the back-end 22 are wholly or partly integrated in a device, e.g. in an expanded switching device 61, preferably in a smartphone, and particularly preferably in a computer system of the road vehicle 1.

40. The method according to any one of claims 1 to 39, wherein the functions of the front-end 7, the switching device 61 and the back-end 22 are wholly or partly integrated in a device, preferably in an extended front-end 7 and more preferably in a vehicle component or system.

41. The method according to claim 1, wherein the vehicle-specific data transmitted to the back end comprises as vehicle data and / or as additionally collected data a selection from the following data: distance traveled since the start of operation, distance traveled since last or any preceding refueling, refueled fuel types or charged types of electricity, route-specific consumed fuel / electricity types, fueled energy or fuel. Fuel quantities, route-specific spent Energiebzw. Seats, line occupancy seats, number of persons transported by line, specific weight transported (gross, tare, net), absolute stoichiometric exhaust gas mass (mass, volume), total stoichiometric exhaust flow, total stoichiometric mass flow of exhaust gas, absolute levels of nitrogen oxide emissions (Volume, mass), nitrogen oxide emissions in a relative quota value, proportion of nitrogen oxide emission in the total amount of exhaust gas, proportion of nitrogen oxide emission in the total exhaust gas volume flow, proportion of nitrogen oxide emission in the total exhaust gas mass flow, absolute fine dust emission amount (volume, mass ), Particulate matter emission in a relative quota value, proportion of particulate matter emission amount in the total exhaust gas quantity, proportion of particulate matter emission in the total exhaust gas volumetric flow, proportion of particulate matter emission in the total exhaust gas mass flow, global geographical vehicle position, global geographical Vehicle position during refueling g, Nitrogen oxide emission, Nitrous oxide emission, Sulfur dioxide emission, Carbon monoxide emission, Particulate matter emission, Noise emission, Oil level, Oil consumption, Tire wear, Tire inflation pressure, Tank level, Tank reach, Battery level, Battery level

7 range, vehicle angle to the longitudinal axis, vehicle angle to the transverse axis, airbag tripping, cooling water temperature, starting behavior, emergency call signal and other data relevant for experts. Method according to one of claims 1 to 41, wherein a selection is given from the following process characteristics:

A GPS position of the road vehicle 1, preferably the GPS position of the road vehicle 1 when it is being refueled or charged, is detected by a suitable vehicle-internal component (GPS antenna, GPS / GLONASS / GALILEO / BEIDOU receiver). and evaluation device or the like), from a suitable vehicle-internal system, from a suitable vehicle-external device (position sensor, navigation device, GPS / GLONASS / GALILEO / BEIDOU receiving and evaluating device, telephone, smartphone, functionally identical device , other user terminal or the like), from the front-end 7 or from the switch 61, and a forwarding of the GPS position data to the back-end 22 takes place;

The vehicle-specific data transmitted to the back end 22 includes GPS position data of the road vehicle 1 as it is being refueled;

In the back-end 22 and / or in one or more components of a data link system, with which the back-end 22 is at least temporarily connected, at least one file (gas station file / database 32) with gas station or charging point-specific Data is maintained or the back-end 22 has access to such a file / database;

The petrol station file / database 32 petrol station and charging point specific data includes GPS location data of the individual petrol stations;

• The petrol station and repository-specific data of the petrol station file / database 32 contain data on the fuel sub-types dispensed at the individual petrol stations, preferably at least data on a selection from the following fuel sub-types: origin / type of the diesel fuel dispensed, origin Type of BioDiesel fuel dispensed, actual mixture ratio for Diesel / BioDiesel mixtures (B7), origin / nature of the petrol dispensed, origin / type of bioethanol dispensed, actual mixture ratio for mixtures of petrol and bioethanol, kerosene of different origin, different bioKerosin Origin, various mixtures of kerosene and bio-kerosene, origin / type of CNG, origin / type of bio-methane, actual mixing ratio for mixtures of CNG and bio-methane, origin / type of LNG, origin / type of LBM (Liquefied BioMethane), actual mixing ratio for mixtures of LNG and LBM, H origin / type of LPG, origin / type of synthetic methane (SynMethans), actual mixing ratio for mixtures of SynMethane of different origin or species, origin / type of hydrogen, actual mixing ratio for mixtures of hydrogen of different origin or species, origin / type of LPG Electricity, actual mixing ratio for mixtures of electricity of different origin, nitrous oxide of different origin, other data on other fuels, etc .;

• in the back-end 22 and / or in one or more components of a data link system, with which the back-end 22 is at least temporarily connected, is detected or calculated, with which fuel or electricity quantities the road vehicle 1 refueled or charged or with what tank / battery charge conditions the fueling

8th or which charges have been started and with which tank / battery charge conditions the refueling has been terminated;

to identify the gas station where the road vehicle 1 was fueled or charged, a comparison takes place, preferably in the back-end 22, between the transmitted from the front end 7 GPS position, the road vehicle 1 during refueling or charging and the GPS locations of the gas stations or charging points stored in the gas station file 32;

for identification of the fuel subspecies, with which the road vehicle 1 was fueled or charged, in the back-end 22 and / or in one or more components of a data link system to which the back-end 22 is at least temporarily connected, a Matching between the refueling data collected by the back-end 22, preferably refueling data relating to the main fuel types, and the refueling-specific fuel sub-types stored in the refueling file 32 of the back-end 22;

in the back-end 22 and / or in one or more components of a data link system, with which the back-end 22 is at least temporarily connected, is detected or calculated which route the road vehicle 1 since the last refueling or since any previous refueling has completed;

in the back-end 22 and / or in one or more components of a data link system, with which the back-end 22 is at least temporarily connected, is detected or calculated from the transmitted vehicle-specific data, which fuel subsets the road vehicle 1 the distance traveled between refueling / recharging and the preceding refueling / recharge;

in the back-end 22 and / or in one or more components of a data link system, with which the back-end 22 is at least temporarily connected, becomes the route-specifically used fuel subspecies, the route-specifically consumed or used energy or fuel quantities, the energy levels (calorific values) of the respective fuel sub-types and the fuel-type specific, based on an energy unit GHG emissions calculated, which GHG emissions quantities the road vehicle 1 on the distance covered, per unit time, per period, per km, per 100 km, per trip, since commissioning, has effectively emanated into the earth's atmosphere in relation to one passenger kilometer or per tonne-kilometers;

in the back-end 22 and / or in one or more components of a data link system, with which the back-end 22 is at least temporarily connected, becomes the route-specifically used fuel subspecies, the route-specifically consumed or used energy or fuel quantities, the energy levels (calorific values) of the respective fuel sub-types and the fuel-type specific, on an energy unit related LCA-GHG emissions calculated, which LCA-GHG emission quantities the road vehicle 1 on the distance covered, per unit time , per period, per km, per 100 km, per trip, since commissioning, based on one passenger kilometer or in terms of one ton-kilometer has effectively emitted into the earth's atmosphere.

9

43. The method according to any one of claims 1 to 42, wherein at least one of the following process characteristics is given:

The vehicle-specific exhaust gas volumetric flow or exhaust gas mass flow is determined by at least one suitable vehicle-internal component (exhaust gas meter or the like) or by a suitable vehicle-external device and transmitted to the front-end 7 or the switching device 61;

The vehicle-specific exhaust gas volumetric flow or exhaust gas mass flow is determined indirectly from other vehicle-specific operating data, preferably from the air mass flow supplied to the engine, and transmitted to the front-end 7 or the switching device 61;

The vehicle-specific data transmitted to the back-end 22 includes exhaust gas data of the road vehicle 1, preferably total exhaust gas quantity data;

In the back-end 22 and / or in one or more components of a data link system, with which the back-end 22 is at least temporarily connected, data are acquired, calculated, stored or exported, which indicate which amounts of exhaust gas (volume , Masses) the road vehicle 1 on a certain route, per unit time, per period, per km, per 100 km, per trip, since startup, as a volume fraction of the exhaust gas flow rate, as mass fraction of the exhaust gas mass flow, based on a passenger-km, volume related to a Passenger-kilometer, mass-based to one tonne-kilometers or volume-related to one tonne-kilometer.

44. The method according to any one of claims 1 to 43, wherein in the road vehicle 1, a device (microcontroller, NO _x sensor, N0 ₂ sensor, according to the principle of conductivity change of easily oxidizable and reducible gases working sensor or the like) is used which is suitable for determining and communicating via a suitable data interface with which nitrogen oxide emission levels (concentrations) the exhaust gas volume flow of a road vehicle 1 is loaded, preferably taking into account the dry / wet correction factor, the nitrogen oxide emission values are determined and hereinafter vehicle-specific analogously to the determination of the GHG emissions, it is ascertained how high the nitrogen oxide emission mass flow and / or the nitrogen oxide emission volume flow of a road vehicle 1 absolutely, per unit of time, per period, per km, per 100 km, per journey, since commissioning, as a volume fraction of the exhaust gas volume flow, as a mass fraction of Abgasma ssestroms, based on one passenger-kilometer, volume-related to one passenger-kilometer, mass-related to one ton-kilometer, volume-related to one ton-kilometer or in proportion to the traveled distance.

45. The method according to any one of claims 1 to 44, wherein at least one of the following process characteristics is given:

• The vehicle-specific proportion of at least one nitrogen oxide in the exhaust gas flow rate or the proportion of at least one nitrogen oxide in the exhaust gas mass flow of at least one suitable vehicle-internal component (NO _x sensor, N0 ₂ sensor, according to the principle of conductivity change of light oxidizable and reducible gases operating sensor or the like) or by a suitable vehicle-external device and transmitted to the back-end 22;

10 The vehicle-specific data transmitted from the front-end 7 to the back-end 22 includes nitrogen oxide emission data of the road vehicle 1;

In the back-end 22, data is recorded, calculated, stored or exported, which indicate which amounts of nitrogen oxide (volume, mass) and / or nitrogen oxide content (proportions of the exhaust gas) the road vehicle 1 on a specific route, per unit time, per period, per km, per 100 km, per trip, since commissioning, as a volume fraction of the exhaust gas flow, as mass fraction of the exhaust gas mass flow, mass-related to a passenger-kilometer, volume-related to a passenger-kilometer, mass-based to one ton-kilometer or volume-related to one ton-kilometer emitted Has.

46. The method according to any one of claims 1 to 45, wherein in the road vehicle 1, a device (particulate matter sensor, particle sensor, soot particle sensor, working with special differential signal processing sensors or the like) is used, which is suitable to determine and a suitable data interface to tell with which particulate emissions of the exhaust gas mass flow or the exhaust gas flow rate of a road vehicle 1 is loaded, and below vehicle-specific analog determination of the GHG emission is determined how high the particulate matter emission mass flow and / or the particulate matter emission volume flow of a road vehicle 1 absolute, per unit time, per period, per km, per 100 km, per trip, since commissioning, as a volume fraction of the exhaust gas volumetric flow, as mass fraction of the exhaust gas mass flow, based on a passenger kilometer, volume based on a passenger kilometer, based on one tonne-kilometers, volume related to one tonnes or kilometers in proportion to the distance traveled.

47. The method according to any one of claims 1 to 46, wherein at least one of the following process characteristics is given:

• The vehicle-specific proportion of particulate matter in the exhaust gas volumetric flow and / or the proportion of particulate matter in the exhaust gas mass flow is at least one suitable vehicle-internal component (particulate matter sensor, particle sensor, particulate matter sensor, working with special differential signal sensors or the like) or by a suitable vehicle-external device;

The vehicle-specific data transmitted to the back-end 22 includes fine dust data of the road vehicle 1;

In the back-end 22, data are recorded, calculated, stored or exported, which indicate which particulate matter (volume, mass) and / or particulate matter (proportions of the exhaust gas) the road vehicle 1 has emitted on a certain route.

48. The method according to any one of claims 1 to 47, wherein in the road vehicle 1, a device (seat belt, ultrasonic or functionally identical sensor) is used, which is suitable to determine and communicate over a suitable data interface or to keep retrievable how many seats are occupied in this road vehicle 1 on which route section, and is subsequently determined vehicle-specifically analogous to the determination of GHG emissions, such as high fuel consumption, power consumption, GHG emissions, C0 ₂ emissions, the LCA-C0 ₂ emissions, particulate matter emissions, nitrogen oxide emissions or other emissions in absolute terms, per passenger kilometer or per passenger per unit of time.

11

49. The method according to any one of claims 1 to 48, wherein in the road vehicle 1, a device (pressure sensor, load sensor, balance or the like) is used, which is suitable to determine and communicate via a suitable data interface, with which payload (net load) or Gross load is the road vehicle 1 on which stretch of road is loaded, and is subsequently determined in a vehicle-specific manner analogous to the determination of GHG emissions, such as fuel consumption, power consumption, GHG emissions, C0 ₂ emissions, LCA-C0 ₂ Emissions, emissions of particulate matter, emissions of nitrogen oxides or other emissions in absolute terms, in each case per tonne or per tonne per unit of time.

50. The method according to any one of claims 1 to 49, wherein instead of the LCA-C0 ₂ emission STOE chiometrische C0 ₂ emission can be determined.

51. The method according to one of claims 1 to 50, in which a selection of the following vehicle emissions is determined analogously to the GHG emissions vehicle-specific: hydrocarbons, hydrocarbons differentiated according to methane and non-methane hydrocarbons, benzene, carbon monoxide, ammonia, di- Nitrogen oxide (nitrous oxide), sulfur dioxide, noise.

52. The method as claimed in claim 51, in which specific microcontrollers (sensors) which are suitable for measuring the respective emission and transmitting the measured values, preferably to the front-end 7, are used for determining the vehicle emissions, particularly preferably to the switching device 61.

53. Method according to one of claims 1 to 52, in which the vehicle-specifically determined data or values are aggregated according to at least one of the following criteria or features: a) road vehicle type, b) road vehicle model, c) engine type, d) Engine model, e) manufacturer, f) motor vehicle class (eg upper class, middle class, etc.), g) other motor vehicle segment, h) customer segment, i) district, j) city, k) state, I) drive type / - technology (diesel, petrol, CNG, LPG, electric, hydrogen etc.), m) main fuel type (including electricity), n) fuel and electricity subspecies, o) period, p) period (eg minute, hour, Day, week, month, quarter, year or a fraction of these periods), q) distance, r) mileage, s) tonne-kilometers, t) passenger-kilometers, u) other characteristics and criteria.

54. The method as claimed in one of claims 1 to 53, in which the determined data or values are transmitted with or without intermediate storage via the communications network (Internet, mobile radio, cable network, data network and the like) or by post letter to at least one of the following addressees: a driver of a specific vehicle, b) a holder of a specific vehicle, c) a tax authority, d) a municipal authority, e) a transport authority such as the Federal Motor Transport Authority, f) an environmental authority, g) a vehicle manufacturer, h) a vehicle tuner, i) a vehicle dealer, j) an operator of an internet community, k) a leasing company, I) an insurance company, m) a fuel manufacturer, n) a power producer, o) a tire manufacturer, p) a research institute, q) an environmental institute, r) a GO, s) a company, t) an NGO, u ) another interested body.

55. The method according to any one of claims 1 to 54, wherein it is determined by the front-end 7 that a refueling / charging takes place, preferably by means of at least one in the front-end. 7

12 stored work instruction, and after completion of the refueling first a storage of refueling relevant data takes place and then a transfer of refueling data from the front-end 7 in the communication network or from the front-end 7 to the switching device 61, the corresponding record a selection of the following Data includes: Refueling / charging odometer reading, Tank level (charge state) at start of refueling / charging, Tank level at completion of refueling / charging, Filling quantity, Amount of charged electricity, Fuel main types, Fuel subspecies, Electricity type, Electricity Sub-type, GPS position at refueling, vehicle ID, ID of the front-end, ID of the switch 61.

56. A system 10, 40, 60, 70, 80, 90, 100, 110, 120, 130 for carrying out the method according to claim 1 comprising

an electronic front-end 7, which is connected to at least one electronic component of a road vehicle 1 and is suitable for obtaining, reading and storing data therefrom and vehicle-specific data or a version of this data directly or indirectly obtained from this electronic component to transmit to a backend 22,

a back-end 22, the first, at least one file or database with vehicle-specific

Data (vehicle file / database 30) and at least one file or database with fuel-specific data (fuel file / data bank 31) comprises or at least temporarily connected to one or more components of a data composite system, the a vehicle file / database 30 and a fuel file / database 31, and secondly capable of receiving and processing vehicle-specific data, characterized in that the back-end 22 or one or more components of a data-sharing system with which the back-end 22 is at least temporarily connected, are suitable for detecting or calculating a travel distance covered by the road vehicle 1,

the back-end 22 or one or more components of a data link system, to which the back-end is at least temporarily connected, are adapted to determine or calculate which fuel types and / or types of power the road vehicle 1 consumes on that route Has,

the back end 22 or one or more components of a data link system to which the back end 22 is at least temporarily connected are adapted to determine or calculate which fuel and / or electricity quantities the road vehicle 1 consumes on that route Has.

57. A system according to claim 56, wherein the fuel-specific (including power-type specific) data of the fuel file / database 31 includes data on the greenhouse gas emission of at least one fuel or at least one stream type and wherein the back End 22 is suitable, from the traveled distance of the road vehicle 1, the fuel consumed on this route fuels, the consumed on this route fuel and / or electricity quantities and the fuel / electricity-specific GHG emissions

13 to calculate which GHG emission quantities (masses, volumes) the road vehicle 1 has emitted on the traveled route into the earth's atmosphere.

58. A system according to claim 56 or 57, wherein the transmission of the vehicle-specific data obtained from the electronic component of the road vehicle 1 or the version of this data to the back-end 22 is wireless over a communication network and / or the back End 22 receives and processes the vehicle-specific data from a communication network.

A system as claimed in any one of claims 56 to 58, wherein the travel distance traveled by the road vehicle 1 is defined as the distance traveled by the road vehicle 1 between two refuelings or between several refuelings, and preferably includes partial journeys made between two refueling operations and more preferably individual trips (trips), the single trip (the trip) being defined as the distance traveled between cranking and turning off the engine.

60. A system according to any of claims 56 to 59, wherein the detection and / or calculation results produced by the back-end 22 are usable by at least one user, preferably from a selection of the following uses: accessible to individual users and / or companies a website; for institutions and / or companies visible and / or retrievable from the back-end 22; for at least one software application retrievable from the back-end 22, from a web server or from an external database; transferable to a computer or a computer system; Transmitted to an electronic communication terminal; transferable to an internet computer; transferable to a data link system; transmitted by e-mail to at least one user; retrievable storage in a back-end internal file or database; retrievable storage in a back-end external file or database; Use in any other way.

61. A system according to any one of claims 56 to 60, wherein the fuel specific data is differentiated by main fuel and fuel sub-types and the fuel file / database 31 is constructed accordingly.

62. A system according to any one of claims 56 to 61, wherein the main fuel species comprise a selection from the fuel groups of diesel fuels, gasolines, kerosene fuels, natural gas (CNG) fuels, LNG fuels , LPG fuels, hydrogens, nitrous gases, methanols, various types of electricity, a power mix and other fuel groups and the fuel file / database 31 is constructed accordingly and / or

in which the fuel subspecies comprises a selection of the following fuel sub-types and the fuel file / database 31 is structured accordingly: diesel fuels of different origin, biodiesel types of different origin, various mixtures of diesel fuels and biodiesel types, gasoline fuels of various origins, Bioethanols of various origins, various mixtures of petrol and bioethanols, CNG of different origin, (bio) methane of different origin, various mixtures of CNG and (bio) methane, LNG of different origin, LBM (Liquefied BioMethane) of different origin, various mixtures of LNG and LBM , LPG of different origin, synthetic

14 Nice methane (SynMethane) of different origin, various mixtures of SynMethane of different origin, various mixtures of SynMethane and CNG, various mixtures of SynMethane and BioMethan, hydrogen from different sources, various mixtures of hydrogen from different sources, electricity from different sources, various mixtures of electricity from different sources , other fuels of different origins and other fuel sub-types.

63. A system as claimed in any one of claims 56 to 62, wherein life cycle greenhouse gas emissions (LCA GHG emissions) determined by Life Cycle Analysis (LCA) are preferably the total LCA GHG emissions of the greenhouse gas emissions Road vehicle 1 include and particularly preferably the LCA-GHG emissions of the road vehicle 1 are divided into gas types and reported.

64. A system according to any one of claims 56 to 63, wherein the vehicle-specific data transmitted to the back-end 22 comprises odometer counts or traveled distances, or the back-end 22 is adapted to determine the traveled distances from other vehicle-specific data.

65. A system according to any one of claims 56 to 64, wherein the front end 7 or a device connected to the front end 7 is adapted to calculate the distance covered and / or the amount of fuel or electricity consumed.

66. A system according to any one of claims 56 to 65, wherein the vehicle-specific data transmitted to the back-end 22 comprises data on tank levels, vehicle battery charge levels, or fuel consumption (including power consumption), or the back-end 22 is suitable to determine the fuel and / or power consumption values, preferably the route-specific fuel and / or power consumption values from other vehicle-specific data.

67. A system according to any one of claims 56 to 66, wherein the fuel-specific data of the fuel file / database 31 comprises data on the energy content or calorific value of at least one fuel or in which the fuel file / database 31 is for at least A type of fuel or at least one type of current includes energy-specific (energy unit-related) GHG emission data, preferably energy-specific (energy unit-related) LCA-GHG emission data.

68. A system according to any one of claims 56 to 67, wherein the back-end 22 or one or more components of a data link system to which the back-end 22 is at least temporarily connected are adapted to the route-specific quantitative fuel consumption using the fuel-specific energy contents or calorific values to convert into a route-specific energy input and / or to calculate the GHG emission, preferably the LCA-GHG emission, from the route-specific energy input and the energy-specific (LCA) GHG emission.

A system according to at least one of claims 56 and 68, wherein the back-end 22 or one or more components of a data-sharing system with which the back-end 22 is connected

15 is at least temporarily connected, suitable to calculate the GHG emission, preferably the LCA-THG emission, from the route-specific amount of energy input and the energy-specific (LCA) GHG emission.

70. A system as claimed in any one of claims 56 to 69, wherein the back-end 22 or one or more components of a data link system to which the back-end 22 is at least temporarily connected are adapted to the determined route-specific values of the road vehicle into other vehicle and / or route-specific quotas, preferably in common vehicle and / or route-specific quotas (eg in fuel consumption / distance, energy consumption / route, fuel consumption / 100 km, energy consumption / km, energy use (amount ) per year, LCA-THG emission (s) in gC0 ₂ -eq / km, C0 ₂ -eq emissions per month, C0 ₂ emissions per year and the like).

71. A system according to any one of claims 56 to 70, wherein the front-end 7 consists of one of the following devices and this device is adapted to receive vehicle-specific operating data via a suitable interface: OBD interface module, OBD memory module, OBD adapter, OBD2 adapter, client computer device, PC, laptop, PDA, telephone, internet enabled telephone, wireless communication, WiFi enabled devices, UWB hub, smartphone, navigation system, computer system, peripheral connectivity Module, display, other front-end device.

72. A system according to any of claims 56 to 71, wherein the electronic component to which the front end 7 is connected in the road vehicle 1 consists of a selection of the following components: engine control unit ECU, electronic control unit ( Electronic Control Unit (ECU), Electronic Control Module (ECM), Power Control Module (PCM), OBD Compliant Vehicle Internal Computer System, Shared Standardized Electronic Bus, On-Board Computer Network , OBD2 bus, Proprietary or manufacturer-specific electronic system, microcontroller, pressure sensor, electrical switch, mechanical switch, magnetic switch, pneumatic switch, optical sensor, light sensor / photocell, sound sensor, sonar system, radar system, proximity sensor, infrared Sensor, temperature sensor, gas sensor, particle sensor, balance, voltage sensor, amperage sensor.

73. A system according to any one of claims 56 to 72, wherein the parts of the back-end 22 comprise a selection of: host computer, host computer system, gateway computer, data receiver / transmitter Module, microprocessor, CPU, data analysis module, data processing module, data storage (module), web server and / or wherein the functions of the parts of the backend 22 are performed by one or more of these devices.

74. A system according to any one of claims 56 to 73, wherein the front-end 7 transmits the vehicle-specific data or a version thereof via a connection to a switch 61 adapted to receive that data from the front-end 7 and transmit it or forward a version of this data to the back-end 22 via a communication network.

16

75. A system according to claim 74, wherein the switch 61 is a selection of: mobile user communications terminal, navigation device, telephone, laptop, PC, electronic camera, mobile vehicle communication device, mobile tower with respective receiving and transmitting devices, Wi-Fi outer , Smartphone, tablet, PDA, communication device with Internet access, communication terminal with Internet access, other interactive access to a communication network or the like.

76. A system according to claim 74 or 75, wherein the connection between the front end

7 and the switching device 61 is wireless and preferably of a Bluetooth ^® - is compound or an 802.11b connection or wherein the connection between the front end 7 and the switching device is made 61 via a plug contact or via cable and preferably a USB Connection is.

77. A system according to any one of claims 74 to 76, wherein the switch 61 is adapted to receive the data received from the front-end 7, a version thereof, and / or additional data not transmitted from the front-end 7 via a To transmit selection from the following communication networks to the back-end 22: mobile radio network, terrestrial mobile radio network, satellite-based mobile radio network, Internet, fixed telephone network, cable network, data network, other communication network.

78. A system according to any one of claims 56 to 77, wherein the road vehicle 1 has a unique identification, preferably a numeric or alphanumeric identification number, and / or wherein the front-end 7 and / or the switching device 61 corresponds to Road vehicle 1 are assigned.

79. A system according to any one of claims 56 to 78, wherein the front end 7 is connected to a vehicle diagnostic system of a road vehicle 1 or to a part of a vehicle diagnostic system, preferably to the legally prescribed OBD system of the road vehicle, particularly preferably with the OBD2 system 5 of the road vehicle and in particular with a successor system of the OBD2 system 5.

80. A system according to any one of claims 56 to 79, wherein the front end 7 receives the vehicle-specific data via an assembly line diagnostic link (ALDL) plug contact, via an OBD plug contact or via an SAE plug contact, preferably via a OBD2 plug contact, particularly preferably via an SAE J1962 plug contact and in particular via a successor model of the OBD2 plug contact.

81. A system according to any one of claims 56 to 80, wherein the front-end 7 is adapted to use a selection of the following communication protocols for reading the vehicle-specific data from the at least one electronic component of the road vehicle: SAE-J1850 - VPW (Ford), SAE-J1850-VPWM (GM), ISO, ISO 9141-2 (Toyota & most European manufacturers), KWP, KWP 2000 (some Hyundai & Mercedes models), CAN (Next-Generation Vehicles as of 2004), a successor protocol to one of these protocols.

82. A system according to any of claims 56 to 81, wherein the parts of the front-end 7 comprise a selection of the following components: housing, OBD connector, OBD interface, gateway

17 Module with driver, signal conditioner, microprocessor (eg ARM7, ARM9), CPU, program memory, data memory, clock, Bluetooth antenna, Bluetooth transmitter module, Bluetooth receiver module, mobile radio antenna, mobile radio transceiver module, SIM Card slot, SIM card, WiFi interface, interface for memory expansion, memory expansion, microcontroller, antenna for GPS signals, evaluation unit for GPS signals, internal battery or battery, electronics for controlling and / or controlling the power supply , serial interface for peripheral devices (for example, second modem, wireless transmit / receive unit, Blue- tooth ^® send / receive unit, 802.11b transmitter / receiver unit), cable or circuit board tracks.

83. A system according to any one of claims 56 to 82, comprising at least one device adapted to receive GPS signals from satellites of the US NAVSTAR-G PS system, the Russian GLONASS system, the European GALILEO system and or the Chinese BEIDOU system and convert it to GPS coordinates.

84. A system according to claim 83, comprising means adapted to add GPS positions to the vehicle-specific data transmitted to the back-end 22, said device preferably being a member or system of the road vehicle, more preferably the front End 7 and in particular the switching device 61.

85. A system according to any one of claims 56 to 84, wherein the front-end 7 is adapted to provide the data acquisition with an electronic time and / or date stamp.

86. A system according to any one of claims 56 to 85, wherein the fuel file / database 31 is adapted to receive, store and retrieve properties, features, indications, values or data, preferably LCA-C0 ₂ - Emission values, particularly preferably the LCA-C0 ₂ emission values of a selection from the main fuel types gasoline, diesel, kerosene, CNG, LNG, LPG, methanol, electricity, hydrogen, nitrous oxide and in particular the LCA-C0 ₂ emission values of a selection from the Fuel subspecies Diesel of different origin, BioDiesel of different origin, various mixtures of diesel and biodiesel, gasoline of different origin, bioethanol of different origin, various mixtures of gasoline and bioethanol, kerosene of different origin, BioKerosin different origin, various mixtures of kerosene and BioKerosin, CNG different Origin, BioMethane of different origin, various mixtures of CNG and BioMethane, LNG of different origin, LBM (Liquefied BioMethane) of different origin, various mixtures of LNG and LBM, LPG of different origin, nitrous oxide of different origin, synthetic methane (SynMethan) of different origin, various mixtures of SynMethane of different origin, hydrogen of different origin, various mixtures from hydrogen of different origin, electricity of different origin, various mixtures of electricity of different origin, other fuels of different origin and the like).

87. A system according to any one of claims 56 to 86, wherein the back-end 22 or one or more components of a data link system to which the back-end 22 is at least temporarily connected are suitable from the transmitted vehicle-specific Vehicle specific data to calculate at least one of the following technical values to save

18 and / or via a suitable data interface: the emission of (LCA) C0 ₂ equivalents in an absolute amount, the (LCA) C0 ₂ eq emission amount per trip, the (LCA) C0 ₂ eq Emission quantity per period (day, week, month, year, vehicle service life, etc.), the (LCA) C0 ₂ eq emission quantity between two refuelings, the emission of (LCA-) C0 ₂ equivalents in a relative quota value , the (LCA) C0 ₂ eq emission quantity per km of driving distance, the (LCA) C0 ₂ eq emission quantity per 100 km of driving distance, the (LCA) C0 ₂ eq emission quantity per fuel quantity (kilogram, ton, Liters, gallons), the (LCA) C0 ₂ eq emission quantity per unit of energy (MJ, kWh), the emission of (LCA-) C0 ₂ equivalents in other technical representations or values.

88. A system according to any one of claims 56 to 87, wherein the front-end 7 is an OBD2 adapter, preferably a successor model of the OBD2 adapter, more preferably an OBD2 adapter which stores the vehicle-specific data via a suitable air interface transmits wirelessly to the switching device 61 or a communication network, and in particular a Golo adapter ("Remote Diagnosis In Car Telematic Device") of Launch Tech Co or a comparable adapter this or another manufacturer.

89. A system according to any one of claims 56 to 88, wherein the functions of the front-end 7 and the switch 61 are wholly or partly integrated in one device or in which the functions of the switch 61 and the back-end 22 are wholly or partly are integrated in a facility, eg in an extended switching device 61, in a smartphone or in a computer system of the road vehicle.

90. A system according to any one of claims 56 to 88, wherein the functions of the front-end 7, the switch 61 and the back-end 22 are wholly or partly integrated in one device, preferably in an extended front-end 7 and more particularly preferably in a vehicle component or system.

91. A system according to any one of claims 56 to 90, wherein the vehicle-specific data transmitted to the back-end 22 comprises as vehicle data and / or as additionally collected data a selection of the following data: distance traveled since start-up Distance traveled since last or any preceding refueling, fuel types or charged types of electricity, route-specific consumed fuel / electricity types, refueled energy or fuel. Fuel quantities, route-specific spent Energiebzw. Seats, line occupancy seats, number of persons transported by line, specific weight transported (gross, tare, net), absolute stoichiometric exhaust gas mass (mass, volume), total stoichiometric exhaust flow, total stoichiometric mass flow of exhaust gas, absolute levels of nitrogen oxide emissions (Volume, mass), nitrogen oxide emissions in a relative quota value, proportion of nitrogen oxide emission in the total amount of exhaust gas, proportion of nitrogen oxide emission in the total exhaust gas volume flow, proportion of nitrogen oxide emission in the total exhaust gas mass flow, absolute fine dust emission amount (volume, mass ), Particulate matter emission in a relative quota value, proportion of particulate matter emission amount in the total exhaust gas quantity, proportion of particulate matter emission in the total exhaust gas volumetric flow, proportion of particulate matter emission in the total exhaust gas mass flow, global geographical vehicle position, global geographical Vehicle position during refueling g, nitrous oxide emission, nitrous oxide emission, sulfur dioxide emission, carbon monoxide emission, particulate matter emission, noise emission, oil level, oil consumption,

19 Tire wear, Tire inflation pressure, Tank level, Tank reach, Battery state of charge, Battery range, Vehicle angle to longitudinal axis, Vehicle angle to the transverse axis, Airbag triggering, Cooling water temperature, starting behavior, emergency signal and other relevant data for professionals.

A system according to any one of claims 56 to 91, wherein a selection is given from the following system features:

The system comprises a device which is suitable for detecting the GPS position of the road vehicle 1, preferably the GPS position of the road vehicle 1 during its refueling (a vehicle-external system, a navigation device, a NAVSTAR GPS / GLONASS / GALILEO / BEIDOU receiving and evaluating device or the like, a vehicle internal system, the front-end 7 or the switch 61);

The system comprises a device or facility combination capable of relaying determined GPS position data to the back-end 22 (front-end 7, switch 61 or combination of front-end 7 and switch 61);

The vehicle-specific data transmitted from the front-end 7 or from the exchange 61 via the communication network to the back-end 22 includes GPS position data of the road vehicle 1 as it is being refueled;

The back-end 22 and / or one or more components of a data-sharing system to which the back-end 22 is at least temporarily connected include at least one file of fueling point-specific data (gas station file / database) 32);

The petrol station file / database 32 petrol station and charging point specific data includes GPS position data of individual petrol stations;

• The petrol station and repository-specific data of the petrol station file / database 32 contain data on the fuel sub-types dispensed at the individual petrol stations, preferably at least data on a selection from the following fuel sub-types: origin / type of the diesel fuel dispensed, origin Type of BioDiesel fuel dispensed, actual mixture ratio for Diesel / BioDiesel mixtures (B7), origin / nature of the petrol dispensed, origin / type of bioethanol dispensed, actual mixture ratio for mixtures of petrol and bioethanol, kerosene of different origin, different bioKerosin Origin, various mixtures of kerosene and bio-kerosene, origin / type of CNG, origin / type of bio-methane, actual mixing ratio for mixtures of CNG and bio-methane, origin / type of LNG, origin / type of LBM (Liquefied BioMethane), actual mixing ratio for mixtures of LNG and LBM, Origin / type of LPG, origin / type of synthetic methane (SynMethans), actual mixing ratio for mixtures of Syn methane of different origin or type, origin / type of hydrogen, actual mixing ratio for mixtures of hydrogen of different origin or species, origin / species the current, actual mixing ratio for mixtures of electricity of different origin, nitrous oxide of different origin, other data on other fuels, etc .;

20 the back-end 22 and / or one or more components of a data link system, with which the back-end 22 is at least temporarily connected, are suitable for detecting or calculating with which fuel or electricity quantities the road vehicle 1 refuels resp has been charged or with which tank / battery states the refueling has started and with which tank / battery charge conditions the refueling has been terminated; the back-end 22 and / or one or more components of a data link system, with which the back-end 22 is at least temporarily connected, are suitable for matching the filling station at which the road vehicle 1 was refueled or charged between the GPS position transmitted by the front-end 7, which the road vehicle 1 had at the time of refueling, and the GPS positions of the refueling points stored in the refueling point file 32;

the back-end 22 and / or one or more components of a data link system, with which the back-end 22 is at least temporarily connected, are suitable for identifying the fuel subspecies with which the road vehicle 1 was fueled or charged, make a match between the refueling data acquired by the back-end 22, preferably refueling data relating to the main fuel types, and the refueling-specific fuel sub-types stored in the refueling file 32 of the back-end 22;

the back end 22 and / or one or more components of a data link system to which the back end 22 is at least temporarily connected are capable of detecting or calculating which route the road vehicle 1 has been since the last refueling or any previous one completed refueling;

the back-end 22 and / or one or more components of a data link system, with which the back-end 22 is at least temporarily connected, are capable of detecting from the transmitted vehicle-specific data or calculating which fuel subsets the Road vehicle 1 has deployed on the route, which has covered it between a refueling / charging and the preceding refueling / charging;

the back-end 22 and / or one or more components of a data link system, with which the back-end 22 is at least temporarily connected, are suitable, from the route-specifically used fuel subspecies, the route-specifically consumed or used To calculate the quantities of fuels (calorific values) of the respective fuel sub-types and the fuel-subgroup-specific GHG emissions related to an energy unit, which GHG emission quantities the road vehicle 1 on the traveled distance, per unit time, per period, per km, per 100 km, per trip, since commissioning, has effectively emanated into the earth's atmosphere in relation to one passenger kilometer or per tonne-kilometers;

the back-end 22 and / or one or more components of a data link system, with which the back-end 22 is at least temporarily connected, are suitable, from the route-specifically used fuel subspecies, the route-specifically consumed or used Quantities of energy or fuel, the energy content (calorific values) of the respective fuel sub-types and the fuel subspecies

21 to calculate specific LCA-GHG emissions related to an energy unit, which LCA-GHG emission quantities the road vehicle 1 on the distance covered, per unit of time, per period, per km, per 100 km, per trip, since commissioning, based on a Passenger-kilometer or, in terms of one ton-kilometer, has effectively emitted into the Earth's atmosphere.

93. A system according to any one of claims 56 to 92, wherein a selection is given from the following system features:

The system comprises a vehicle-internal device which is suitable for directly determining the exhaust gas volumetric flow or exhaust gas mass flow and transmitting it to the front end 7 or the switching device 61 (exhaust gas quantity meter or the like);

The system comprises a vehicle-external device capable of directly detecting the exhaust gas volumetric flow or exhaust gas mass flow and transmitting it to the front end 7 or the switching device 61 (retrofitted exhaust gas meter or the like);

The system comprises a vehicle-internal device that is capable of supplying data and transmitting it to the front-end 7 or the switching device 61, from which the vehicle-specific exhaust gas volume flow or exhaust gas mass flow can be determined indirectly (eg Air mass meter or the like);

The back-end 22 and / or one or more components of a data link system to which the back-end 22 is at least temporarily connected are capable of acquiring, calculating, storing or exporting data indicating which Exhaust gas amounts (volume, mass) the road vehicle 1 on a certain route, per unit time, per period, per km, per 100 km, per trip, since commissioning, as a volume fraction of the exhaust gas volume flow, as mass fraction of the exhaust gas mass flow, based on a passenger-km, volume-related to one passenger-kilometer, mass-based to one ton-kilometer or volume-related to one ton-kilometer.

94. A system according to any one of claims 56 to 93, wherein in the road vehicle 1 means (microcontroller, NO _x sensor, N0 ₂ sensor, according to the principle of conductivity change of easily oxidizable and reducible gases working sensor or the like) are used which is capable of determining and transmitting via a suitable data interface to the front-end 7 or the switching device 61 with which nitrogen oxide emission levels (concentrations) the exhaust gas volume flow of a road vehicle 1 is loaded, preferably taking into account the dry / Moist correction factor and / or in which the back end 22 or one or more components of a data composite system with which the back end 22 is at least temporarily connected, are suitable for determining from transmitted nitrogen oxide emission values, how high the nitrogen oxide Emission mass flow and / or the nitrogen oxide emission volume flow of a road vehicle 1 absolute, per Time unit, per period, per km, per 100 km, per trip, since commissioning, as a volume fraction of the exhaust gas volumetric flow, as a mass fraction of the exhaust gas mass flow, based on one passenger kilometer, volumetric

22 based on a passenger-kilometer, based on one tonne-kilometers, volume-related to one tonne-kilometer or in relation to the distance traveled.

95. A system according to any one of claims 56 to 94, wherein a selection is given from the following system features:

The system comprises a vehicle-internal device which is suitable for determining the proportion of at least one nitrogen oxide in the exhaust gas volume flow or the proportion of at least one nitrogen oxide in the exhaust gas mass flow (nitrogen oxide concentration) and to the front end 7 or the switching device 61 to transmit (NO _x sensor N0 ₂ sensor, according to the principle of conductivity change of easily oxidizable and reducible gases working sensor or the like);

The system comprises a vehicle-external device which is suitable for determining the proportion of at least one nitrogen oxide in the exhaust gas volume flow or the proportion of at least one nitrogen oxide in the exhaust gas mass flow (nitrogen oxide concentration) and to the front end 7 or the switching device 61 (subsequently installed NO _x sensor N0 ₂ sensor, according to the principle of conductivity change of easily oxidizable and reducible gases working sensor or the like);

The vehicle-specific data transmitted from the front-end 7 to the back-end 22 includes nitrogen oxide emission data of the road vehicle 1;

The back-end 22 and / or one or more components of a data link system to which the back-end 22 is at least temporarily connected are capable of acquiring, calculating, storing or exporting data indicating which Nitrogen oxide quantities (volumes, masses) and / or nitrogen oxide contents (proportions of the exhaust gas) the road vehicle 1 on a specific route, per unit time, per period, per km, per 100 km, per trip, since commissioning, as a volume fraction of the exhaust gas volume flow, as mass fraction of Exhaust gas mass flow, mass-based on a passenger-kilometer, volume-related to one passenger-kilometer, mass-related to one ton-kilometer or volume-related to one ton-kilometer emitted.

96. A system according to any one of claims 56 to 95, wherein in the road vehicle 1 means (particulate matter sensor, particulate sensor, soot particle sensor, using special differential signal method sensors or the like) is used, which is able to determine and To transmit via a suitable interface to the front-end 7 or the switching device 61, with which particulate matter emissions of the exhaust gas mass flow or the exhaust gas flow rate of a road vehicle is loaded.

97. A system as claimed in claim 96, wherein the back-end 22 or one or more components of a data-sharing system to which the back-end 22 is at least temporarily connected are adapted to determine from transmitted particulate matter values how high the particulate matter emission mass flow and / or the particulate matter emission volume flow of a road vehicle 1 absolute, per unit time, per period, per km, per 100 km, per trip, since commissioning, as a volume fraction of the exhaust gas volumetric flow, as mass fraction of the exhaust gas mass flow, based mass to one passenger-kilometer, volume-related to one passenger-kilometer, mass-based to one ton-kilometer, volume-related to one ton-kilometer or in proportion to the distance traveled.

23

98. A system according to any of claims 56 to 97, wherein a selection is given from the following system features:

• The system includes a vehicle-internal device, which is suitable to determine the proportion of particulate matter in the exhaust gas flow rate and / or the proportion of fine particulate bs on the exhaust gas mass flow (particulate matter concentration) and the front-end 7 or the Transfer switching device 61 (fine dust sensor, particle sensor, soot particle sensor, working with special differential signal processing sensors or the like);

• The system includes a vehicle-external device, which is suitable to determine the proportion of particulate matter in the exhaust gas flow rate and / or the proportion of fine particulate bs on the exhaust gas mass flow (particulate matter concentration) and the front-end 7 or the Transfer switching device 61 (subsequently installed particulate matter sensor, particle sensor, soot particle sensor, working with special differential signal processing sensors or the like);

The vehicle-specific data transmitted to the back-end 22 includes fine-b data of the road vehicle 1;

The back-end 22 and / or one or more components of a data link system to which the back-end 22 is at least temporarily connected are capable of acquiring, calculating, storing or exporting data indicating which Particulate matter (volume, mass) and / or particulate matter (proportions of the exhaust gas) has emitted the road vehicle 1 on a specific route.

99. A system according to any one of claims 56 to 98, comprising means (seat belt, ultrasound or functionally identical sensor) adapted to detect and transmit via a suitable data interface to the front-end 7 or switch 61 be kept retrievable, how many seats are occupied in this road vehicle 1 on which Streckena section and / or in which the back-end 22 or one or more components of a data-sharing system with which the back-end 22 is at least temporarily connected, to determine from fueled seat data, such as fuel consumption, electricity consumption, GHG emissions, C0 ₂ emissions, LCA-C0 ₂ emissions, particulate matter emissions, nitrogen oxide emissions or other emissions absolute, per passenger-kilometer or per passenger and time unit fail.

100. A system according to any one of claims 56 to 99, wherein in the road vehicle 1, a device (pressure sensor, load sensor, balance or the like) is used, which is adapted to determine and via a suitable data interface to the front-end 7 or Switching device 61 to transmit or a b to keep track of what payload (net load) or gross load the road vehicle 1 is loaded and / or in which the back-end 22 or one or more components of a data-sharing system, with the back-end 22 is at least temporarily connected, are suitable to determine from transmitted charge data, such as fuel consumption, power consumption, GHG emissions, C0 ₂ emissions, LCA-C0 ₂ emissions, particulate matter emissions, the Emissions of oxides of nitrogen or other emissions in absolute terms, in each case per ton-kilometer or per ton and unit of time.

101. System according to one of claims 56 to 100, which is suitable for determining, in a vehicle-specific manner, a selection of the following vehicle emissions analogously to GHG emissions:

24 hydrocarbons differentiated into methane and non-methane hydrocarbons, benzene, carbon monoxide, ammonia, di-nitrous oxide (nitrous oxide), sulfur dioxide, noise and / or the special microcontroller (sensors) suitable for selecting from the following vehicle Measure emissions and transmit the measured values, preferably to the front end 7, more preferably to the switch 61: hydrocarbons, hydrocarbons differentiated to methane and non-methane hydrocarbons, benzene, carbon monoxide, ammonia, di-nitrous oxide (nitrous oxide), sulfur dioxide , Noise.

102. System according to one of claims 56 to 101, in which the back-end 22 or one or more components of a data combination system, with which the back-end 22 is at least temporarily connected, are suitable for the vehicle-specific determined data or To aggregate values according to at least one of the following criteria or characteristics: a) road vehicle type, b) road vehicle model, c) engine type, d) engine model, e) manufacturer, f) motor vehicle class (eg upper class, middle class, etc.), g) other motor vehicle segment, h) customer segment, i) district, j) city, k) state, i) drive type / technology (diesel, petrol, CNG, LPG, electric, hydrogen etc.), m) fuel - main type (including electricity), n) fuel and electricity subspecies, o) period, p) period (eg minute, hour, day, week, month, quarter, year or a fraction of these periods), q) route, r) mileage, s) ton-kilometers, t) passenger-kilometers, u) other characteristics and criteria.

103. System according to one of claims 56 to 102, in which the back-end 22 or one or more components of a data combination system, with which the back-end 22 is at least temporarily connected, are suitable, the determined data or values or without intermediate storage via the communications network (Internet, mobile communications, cable network, data network and the like) or by post to at least one of the following addressees: a) a driver of a specific vehicle, b) a holder of a specific vehicle, c) a tax authority , d) a municipal authority, e) a transport authority such as the Federal Motor Transport Authority, f) an environmental authority, g) a vehicle manufacturer, h) a vehicle tuner, i) a vehicle dealer, j) an operator of an internet community, k) a leasing company, I) an insurance company, m) a fuel manufacturer, n) a power generator, o) a tire manufacturer, p) a research institute, q) an environmental institute, r) a GO, s) a company, t) an NGO, u ) another interested body.

A system according to any one of claims 56 to 103, wherein the front-end 7 is adapted to determine that fueling / recharging is taking place, preferably by means of at least one working instruction stored in the front-end 7, and in this case storing the betan - kung relevant data, the corresponding record includes at least one selection of the following data: odometer reading during refueling / tank, tank level (state of charge) at the start of refueling / charging, tank level (state of charge) at the end of refueling / charging, capacity, charged Amount of electricity, main fuel types, fuel subspecies, electricity type, electricity subspecies, GPS position during refueling.

25