EP3465633A2 - Procédé et système permettant de déterminer les consommations de carburant, utilisations d'énergie et émissions réelles lors de l'utilisation quotidienne de véhicules routiers - Google Patents

Procédé et système permettant de déterminer les consommations de carburant, utilisations d'énergie et émissions réelles lors de l'utilisation quotidienne de véhicules routiers

Info

Publication number
EP3465633A2
EP3465633A2 EP17764511.6A EP17764511A EP3465633A2 EP 3465633 A2 EP3465633 A2 EP 3465633A2 EP 17764511 A EP17764511 A EP 17764511A EP 3465633 A2 EP3465633 A2 EP 3465633A2
Authority
EP
European Patent Office
Prior art keywords
vehicle
data
fuel
specific
emission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP17764511.6A
Other languages
German (de)
English (en)
Inventor
Michael Feldmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Phoenix Ip Bv IO
Original Assignee
Phoenix Ip Bv IO
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Phoenix Ip Bv IO filed Critical Phoenix Ip Bv IO
Publication of EP3465633A2 publication Critical patent/EP3465633A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F01—MACHINES OR ENGINES IN GENERAL; ENGINE PLANTS IN GENERAL; STEAM ENGINES
    • F01N—GAS-FLOW SILENCERS OR EXHAUST APPARATUS FOR MACHINES OR ENGINES IN GENERAL; GAS-FLOW SILENCERS OR EXHAUST APPARATUS FOR INTERNAL COMBUSTION ENGINES
    • F01N9/00—Electrical control of exhaust gas treating apparatus
    • F01N9/007—Storing data relevant to operation of exhaust systems for later retrieval and analysis, e.g. to research exhaust system malfunctions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • B60R16/0236—Circuits relating to the driving or the functioning of the vehicle for economical driving
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F01—MACHINES OR ENGINES IN GENERAL; ENGINE PLANTS IN GENERAL; STEAM ENGINES
    • F01N—GAS-FLOW SILENCERS OR EXHAUST APPARATUS FOR MACHINES OR ENGINES IN GENERAL; GAS-FLOW SILENCERS OR EXHAUST APPARATUS FOR INTERNAL COMBUSTION ENGINES
    • F01N2590/00—Exhaust or silencing apparatus adapted to particular use, e.g. for military applications, airplanes, submarines
    • F01N2590/11—Exhaust or silencing apparatus adapted to particular use, e.g. for military applications, airplanes, submarines for hybrid vehicles
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F01—MACHINES OR ENGINES IN GENERAL; ENGINE PLANTS IN GENERAL; STEAM ENGINES
    • F01N—GAS-FLOW SILENCERS OR EXHAUST APPARATUS FOR MACHINES OR ENGINES IN GENERAL; GAS-FLOW SILENCERS OR EXHAUST APPARATUS FOR INTERNAL COMBUSTION ENGINES
    • F01N2900/00—Details of electrical control or of the monitoring of the exhaust gas treating apparatus
    • F01N2900/06—Parameters used for exhaust control or diagnosing
    • F01N2900/10—Parameters used for exhaust control or diagnosing said parameters being related to the vehicle or its components
    • F01N2900/102—Travelling distance
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F01—MACHINES OR ENGINES IN GENERAL; ENGINE PLANTS IN GENERAL; STEAM ENGINES
    • F01N—GAS-FLOW SILENCERS OR EXHAUST APPARATUS FOR MACHINES OR ENGINES IN GENERAL; GAS-FLOW SILENCERS OR EXHAUST APPARATUS FOR INTERNAL COMBUSTION ENGINES
    • F01N2900/00—Details of electrical control or of the monitoring of the exhaust gas treating apparatus
    • F01N2900/06—Parameters used for exhaust control or diagnosing
    • F01N2900/12—Parameters used for exhaust control or diagnosing said parameters being related to the vehicle exterior
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/10—Internal combustion engine [ICE] based vehicles
    • Y02T10/40—Engine management systems
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/80—Technologies aiming to reduce greenhouse gasses emissions common to all road transportation technologies
    • Y02T10/84—Data processing systems or methods, management, administration

Definitions

  • 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.
  • 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.
  • the EU must reduce greenhouse gas emissions by 80% to 95% by 2050 compared to 1990 levels.
  • emission reductions should reach at least 60% by 2050 compared to 1990 levels, which is 70% of the 2008 level.
  • 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.
  • 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.
  • 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.
  • the driving resistances rolling and aerodynamic drag
  • 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.
  • the stoichiometric fuel consumption is calculated from the exhaust emission.
  • the charge states of the battery are measured instead.
  • 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.
  • T & E 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%.
  • the fuel consumption and emission values determined in this way were not questioned until the VW emissions scandal in 2015.
  • 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.
  • 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.
  • 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.
  • EEM ES European Research Group on Mobile Emission Sources
  • the European Research Group on Mobile Emission Sources 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.
  • the WLTC Worldwide Harmonized Light Vehicles Test Cycle
  • N ECt National Engineering Commission
  • 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).
  • 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).
  • (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.
  • 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.
  • 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.
  • GHG 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.
  • 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 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 2 0) and nitrogen (N 2 ). 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.
  • DE112009000544T5 discloses an improved method and system for exhaust aftertreatment.
  • 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 2 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.
  • 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.
  • the measurement results are multiplied by a dry / wet correction factor.
  • a NO x -Abgas mass flow is calculated from the thus formed NO x concentration of the moist exhaust gas mass flow.
  • 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 2 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 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 2 ) 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.
  • 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.
  • 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.
  • 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.
  • Pfalzgraf can not export data to areas outside the vehicle.
  • 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 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 2 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 2 emissions of a vehicle and provide it for further use, eg via mobile radio (GSM).
  • GSM mobile radio
  • 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.
  • a "fuel conditioner” or an emission-reducing additive such as, in particular, hydrogen, LPG or methane gas
  • Nolte / Schenk also do not indicate that and how the C0 2 -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.
  • OBD systems On-board diagnostic systems
  • 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.
  • 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.
  • 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 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).
  • 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.
  • the engine control unit ECU
  • the engine control unit ECU
  • standardized diagnostic messages Diagnostic Trouble Codes DTCs
  • 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.
  • 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.
  • 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.
  • these data scanners are only used during a workshop visit or on the chassis dynamometer (dynamometer).
  • OBD diagnostic adapters which can be coupled via an OBD connector to the vehicle diagnostic interface (OBD socket).
  • 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 Teaches a wireless, Internet-based vehicle surveillance system based on OBD technology installed in US automobiles since 1996.
  • the host system receives the diagnostic and operational data of the vehicle from the communications network and processes it into vehicle diagnostic records.
  • the host system hosts an Internet web site that displays these vehicle diagnostic records.
  • the host is able to transfer data and work instructions via the communications network to the in-vehicle "wireless appliance.”
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 discloses a system and method for displaying and analyzing vehicle diagnostic data.
  • 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.
  • VIM vehicle interface module
  • 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).
  • 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).
  • Internet wide area network
  • 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.
  • 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.
  • 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).
  • a communication network mobile radio network
  • Internet communication network
  • 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 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.
  • 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.
  • 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.
  • 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%.
  • 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 2 values are not measured nor calculated. Neither (LCA) GHG emission values are determined, nor are route-specific (LCA) GHG emissions determined.
  • US 6928348 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.
  • 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 scken enclosuressystem.
  • the DE102011076638A1 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.
  • 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.
  • 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.
  • 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).
  • GPS global geographical position
  • 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.
  • 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.
  • LCA determination route specific
  • TREMOD Transport Emission Model
  • VDA German Automobile Industry Association
  • VDA German Automobile Industry Association
  • 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.
  • 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.
  • 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.
  • 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.
  • the systems and devices known from the prior art disclosures are not suitable for detecting the life cycle emissions of road vehicles.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • switching equipment smart phone
  • Internet mobile or the like
  • gasoline vehicles consume gasoline or petrol
  • diesel vehicles diesel fuel diesel fuel
  • CNG CNG vehicles CNG CNG vehicles
  • LPG vehicles LPG hydrogen fuel cell vehicles and electric power
  • range extenders i.d.R. two types of fuel are detected and corresponding data is transmitted.
  • 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).
  • 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 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).
  • the (LCA) GHG emission values can also be calculated directly from the fuel consumption if the emission values per fuel sales unit are available.
  • 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 2 equivalent per km, the (LCA) GHG emission rate in GC0 2 equivalent per 100 km, the C0 2 - 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.
  • vehicle sensors eg tank level sensor
  • vehicle systems eg engine control
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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).
  • 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.
  • vehicle-specific file or database vehicle file, vehicle database
  • At least one file or database with fuel-specific data is kept in the back-end.
  • fuel file fuel database
  • the different technical characteristics of the various fuels fuel main types and fuel subspecies
  • 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.
  • 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 ).
  • a special evaluation program evaluates in a first step the vehicle-specific data on fuel consumption (power consumption) transmitted from the communication network.
  • 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).
  • 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).
  • the route-specific (LCA) GHG emission values of the fuels or stream type 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).
  • LCA on energy unit related
  • 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 2 equivalent per km, C0 2 emissions per month or other common quota values.
  • 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.
  • the communications network e.g., Internet
  • 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.
  • drive 100 km, 1,000 km, 5,000 km, 10,000 km, 20,000 km, 50,000 km, 100,000 km
  • time day, week, month, quarter, year etc.
  • event-related workshop visit of the vehicle, expiry of a test interval, TÜV appointment, etc.
  • 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.
  • the front end may 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.
  • an external vehicle diagnostic device / system or another communication terminal can also be used (see above).
  • 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.
  • 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.
  • 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.
  • the switching device is uniquely identifiable. This is e.g. given a unique identification number, which may be both numeric and alphanumeric.
  • 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.
  • 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.
  • 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.
  • 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.
  • the inventive method provides for the use of such an algorithm and the inventive system comprises such an algorithm.
  • 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.
  • 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 ,
  • the switching device 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).
  • the smartphone 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.
  • the user 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.
  • 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.
  • 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
  • This feature is used by data scanners when the vehicle is checked in stand or on chassis dynamometers.
  • 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.
  • 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.
  • 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.
  • the unique route-specific energy input by the fuel-specific (LCA) GHG emission related to one energy unit (MJ, kWh H i) 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • a petrol station file / database is kept next to the vehicle file / database and the fuel file / database.
  • 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.
  • 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).
  • 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.
  • the front-end transfers the calculation result either directly to the back-end or via the switching device.
  • this calculation of the route can also be performed by the special software loaded on the switching device.
  • the front-end transmits only the odometer readings to the back-end or to the switch.
  • 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.
  • the front-end 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.
  • the distance traveled by the vehicle 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.
  • a gyroscope 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.
  • 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.
  • a prerequisite for determining the fuel-specific (LCA) GHG emission quantity which is usually measured in gC0 2 -eq / MJ or in gC0 2 -eq / kWh H i, is the knowledge of the type of fuel.
  • fuels have very different densities, energy contents (calorific values), GHG emission values and in particular LCA-GHG emission values.
  • propulsion technologies are defined by the fuel they use.
  • the drive technology is deposited according to the invention in the vehicle file / database of the backend.
  • 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.
  • CNG petrol and natural gas
  • 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.
  • OBD on-board diagnostic
  • 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).
  • OBD on-board diagnostic
  • 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.
  • OBD on-board diagnostic
  • 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.
  • 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.
  • 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 2 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 front end transmits only the tank levels (battery charge states) to the switching device.
  • 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.
  • 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).
  • the front-end transfers the calculation result either directly to the back-end or via the switching device.
  • the calculation of the fuel consumption quantities can also be performed by the special software loaded on the switching device.
  • the front end transmits only the tank levels (battery charge states) to the switching device.
  • the calculation of the consumed fuel quantities 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 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.
  • 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).
  • 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.
  • 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
  • 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
  • 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 Kraftstoffmannsc. 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.
  • the fuel-specific energy contents 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.
  • the fuel file fuel database
  • the fuel-specific data is stored 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.
  • 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.
  • the back- End 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.
  • vehicle-specific energy or fuel consumption and possibly other data
  • 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.
  • 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 2 -equivalent / MJ or in gC0 2 -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 2 -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.
  • 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.
  • the vehicle file / database is not run and operated in the backend, but on a foreign server.
  • the fuel file / database and the gas station file / database they can also be operated outside the actual back-end.
  • 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.
  • the back end 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.
  • 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.
  • 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.
  • the invention helps to demonstrate that CNG-fueled VW CNG gulfs emit on average 25% less (LCA) GHG CO 2 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 2 footprint of their vehicles actually is as a result of their driving objectives and driving style.
  • LCA 25% less
  • CNG gulfs fueled with BioMethane 70% less CNG gulfs fueled with straw methane even 90% less
  • ERMES European Research Group on Mobile Emission Sources
  • HBEFA Emissions Factor Handbook
  • 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.
  • 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.
  • the front-end (the OBD2 adapter) can be used without further adaptation measures or special versions of all modern road vehicles.
  • 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.
  • 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 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.
  • OBD2 connector 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
  • 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 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.
  • the OBD2 adapter is powered by the vehicle via the OBD2 socket (PIN 16) of the vehicle with the power required for its operation.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a Bluetooth a WiFi / WLAN protocol
  • / or a USB protocol a protocol that supports wireless personal area network (WPAN)
  • 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 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.
  • Diesel of different origin diesel of different origin
  • biodiesel of different origin various
  • 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.
  • 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 2 - equivalents in absolute terms, the (LCA-) C0 2 emissions per trip, the (LCA-) C0 2 - emissions per period (day, week, month, year, vehicle lifetime, etc.), the (LCA-) C0 2 emission amount between two refuelings, the emission of (LCA-) C0 2 equivalents in a relative quota, the (LCA-) C0 2 emission amount per km of travel, the (LCA-) C0 2 emission amount per 100 km of travel , the (LCA) C0 2 emission amount per fuel quantity (kilogram, ton, liter, gallon), the (LCA-) C0 2 emission amount per unit of energy (MJ, kWh) as well as the emission of (LCA-) C0 2 -equivalent
  • 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 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.
  • 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;
  • a suitable vehicle-internal component position sensor, NAVSTAR GPS / GLONASS / GALILEO
  • BEIDOU receiving and evaluation device or the like
  • smartphone other user terminal or the like
  • 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;
  • 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
  • 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;
  • 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 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.
  • the back-end (possibly over a time alignment) more or less effortlessly Determine which fuel subsidence the respective vehicle has fueled.
  • the energy contents (calorific values) and (LCA) emission values of the individual fuel sub-types 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.
  • 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.
  • 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.
  • 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.
  • the inventor proposes to use a device (NO x sensor, N0 2 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.
  • 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.
  • 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 2 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.
  • suitable vehicle-internal component NO x sensor, N0 2 sensor, according to the principle of conductivity change of easily oxidizable and reducible gases operating sensor or the like
  • 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.
  • 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.
  • 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.
  • 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.
  • a device porous matter sensor, particle sensor, soot particle sensor, working with special differential signal processing sensors or the like
  • vehicle-specific analog determination of the (LCA) C0 2 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.
  • 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.
  • knowledge of the route-specific occupancy rate is required.
  • 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.
  • 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).
  • knowledge of the route-specific transport performance is required.
  • 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.
  • 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.
  • 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.
  • the charging duration can be determined by detecting it directly with an electronic stopwatch and transmitting it to the back end.
  • 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);
  • 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
  • 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.
  • 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
  • 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;
  • a vehicle-external device eg refueling station, payment system
  • 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 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 accord
  • 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;
  • 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 viagelradanemometer 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 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;
  • the inventive method and its developments disclosed herein relate to the LCA-C0 2 equivalents in terms of GHG emission.
  • the fuel-specific LCA-GHG emission values 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).
  • 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.
  • Internet Internet, mobile radio, cable network or the like
  • a transport authority
  • 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.
  • 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.
  • OBD on-board vehicle diagnostic
  • 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.
  • OBD on-board vehicle diagnostic
  • the back end 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 ,
  • 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.
  • OBD on-board vehicle diagnostic
  • 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.
  • OBD on-board vehicle diagnostic
  • 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.
  • OBD on-board vehicle diagnostic
  • 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.
  • 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.
  • this at least one component is an electronic vehicle sensor or an electronic vehicle system.
  • this at least one component is an on-board vehicle diagnostic system (OBD system).
  • OBD system on-board vehicle diagnostic system
  • the front-end 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.
  • 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.
  • 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.
  • an external data storage such as a chip (card memory), a USB stick or the like
  • 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.
  • 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.
  • 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.
  • the front-end is suitable for communicating with the outside world via a suitable interface, preferably via a standardized interface.
  • 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.
  • 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.
  • 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.
  • OBD2 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.
  • the front end is an OBD adapter, preferably an OBD2 adapter.
  • 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.
  • 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.
  • 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.
  • 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.
  • the front-end 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.
  • 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.
  • modem mobile radio transmitting / receiving module
  • modem mobile radio antenna
  • 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)
  • power management system eg NAVSTA GPS, GLONASS GPS, GALILEO GPS, BEIDOU GPS
  • the latter makes it possible to remove the OBD2 adapter (the front end) from the OBD system of the vehicle
  • the front-end not only records odometer readings, tank levels and fuel consumption, but also other data and values.
  • 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.
  • 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).
  • vehicle file / data vehicle file / data
  • fuel file / database fuel file / database
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • GHG fuel-specific
  • 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.
  • the back-end preferably additionally comprises at least one third file, namely one with filling station-specific data (filling station file / database).
  • 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.
  • 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.
  • 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.
  • 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.
  • LCA fuel / power type specific
  • 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.
  • 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.
  • 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.
  • 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, Energy administratmen- ge / km, energy input / year, (LCA) GHG emissions in gC0 2 -equivalent / km, C0 2 - emissions / month, C0 2 emissions / year, etc.) using simple mathematical rules.
  • a road vehicle in other vehicle or track-specific quotas eg in fuel consumption / 100 km, Energy Doctor Caremen- ge / km, energy input / year, (LCA) GHG emissions in gC0 2 -equivalent / km, C0 2 - emissions / month, C0 2 emissions / year, etc.
  • 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).
  • 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
  • Fuel-specific data from the fuel file eg the calorific value of Diesel of subspecies Diesel B7.
  • 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 2 emissions per day, C0 2 emissions per week, C0 2 emissions per month, CO 2 emissions per year, CO 2 emissions over the entire vehicle service life, etc.).
  • a device software application, program
  • 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.
  • 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.
  • 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).
  • 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 - / Batterieladezucardin 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.
  • 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 2 equivalents in one absolute amount, the (LCA) C0 2 emission amount per trip, the (LCA-) C0 2 emission amount per period (day, week, month, year, vehicle lifetime, etc.), the (LCA) C0 2 emission amount between two fueling operations, the emission of (LCA-) C0 2 equivalents in a relative quota, the (LCA-) C0 2 emission amount per km of travel, the (LCA-) C0 2 emission amount per 100 km of driving distance (LCA -) C0 2 emission amount per fuel quantity (kilogram, ton, liter, gallon), the (LCA) C0 2 emission amount per unit of energy (MJ, kWh), the emission of (LCA-) C0 2 equivalents in other technical representations or values.
  • the knowledge of these values is useful and advantageous, in part even condition, for the determination
  • 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.
  • 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.
  • 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).
  • LCA on energy unit related
  • 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 2 equivalent, C0 2 emissions per month or other common quota values.
  • 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.
  • 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
  • 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.
  • 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.
  • this facility 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
  • a charging station 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.
  • GPS coordinates global geographic position
  • 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.
  • LCA energy unit related
  • 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.
  • a back-end device software application, program
  • 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.
  • a wide communication network Internet, mobile radio, cable network, telephone network or the like.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • the fuel file / database is particularly suitable for technical properties and characteristics, in particular (LCA) CO 2 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,
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • this integration of the functions in only one device, namely in the front end this must be suitable for this purpose.
  • 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).
  • a vehicle-internal component position sensor, GPS / GLONASS / GALILEO / BEIDOU receiving and evaluation device or the like
  • 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).
  • the inventive system advantageously comprises a front-end adapted to detect the GPS position of the road vehicle.
  • 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.
  • GPS position global geographical position
  • 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
  • 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
  • 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 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.
  • 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 2 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
  • a back-end device 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.
  • 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.
  • 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
  • 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
  • a motor vehicle 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.
  • 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 2 , particulate matter or nitrogen oxide emissions are absolute, per passenger-kilometer or per passenger per unit of time.
  • LCA fuel consumption
  • particulate matter or nitrogen oxide emissions are absolute, per passenger-kilometer or per passenger per unit of time.
  • 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 2 emission, the particulate matter emission or the nitrogen oxide emission is absolute, per ton-kilometer or per tonne and time unit.
  • a device pressure sensor, load sensor or the like
  • the back-end device software application, program
  • 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.
  • 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);
  • 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
  • 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;
  • 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
  • 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;
  • a vehicle-external device eg refueling station, payment system
  • 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 (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;
  • 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.
  • 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 accord
  • 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;
  • 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 viagelradanemometer 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;
  • 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.
  • motor vehicle class eg Upper class, middle class, etc.
  • g) other motor vehicle segment e
  • 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 2 .
  • LCA fuel consumption
  • a system 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,
  • 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.
  • 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.
  • 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;
  • FIG. 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;
  • SIM card mobile communication card
  • FIG. 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;
  • FIG. 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;
  • FIG. 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.
  • FIG. 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;
  • FIG. 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;
  • FIG. 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. 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.
  • 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).
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • GPS system 33 American NAVSTA -G PS, European GALI LEO-GPS, Russian GLONASS GPS, Chinese AT DOU-GPS
  • 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 ü 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • SIM card mobile communication card
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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 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 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,
  • 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 establish a connection.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 9 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.
  • 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.
  • FIG. 10 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.
  • 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.
  • 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.
  • a special software application 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.
  • 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 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.
  • 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.
  • the smartphone 8 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the front-end 7 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).
  • 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.
  • 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).
  • 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.
  • 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).
  • 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 Abiauf suits 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).
  • 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.
  • back-end 22 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).
  • 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).
  • ECM Electronic Control Module
  • PCM Power Control Module
  • 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.
  • the front end 7 is an OBD2 adapter.
  • 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.
  • gateway communication interface
  • 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).
  • G PS system 33 American NAVSTAR-G PS, European GALI LEO GPS, Russian G LONASS GPS, Chinese AT DOU GPS, not shown
  • 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.
  • the following interface devices 56 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.
  • 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.
  • the gateway 45 or the microprocessor 51 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.
  • 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).
  • ECM Electronic Control Module
  • PCM Power Control Module
  • 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 1 , 43 2 , 43 3 ) are supplied.
  • ECU 43, 43 1 , 43 2 , 43 3 Electronic Control Units
  • the front-end 7 is also an OBD2 adapter.
  • 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.
  • gateway communication interface
  • 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).
  • G PS system 33 American NAVSTAR-G PS, European GALI LEO GPS, Russian G LONASS GPS, Chinese AT DOU GPS, not shown
  • 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.
  • the following interface devices 56 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.
  • 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.
  • 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).
  • ECM Electronic Control Module
  • PCM Power Control Module
  • 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 1 , 43 2 , 43 3 ) are supplied.
  • ECU 43, 43 1 , 43 2 , 43 3 Electronic Control Units
  • the front-end 7 is also an OBD2 adapter.
  • 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.
  • gateway communication interface
  • 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).
  • 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.
  • 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.
  • the following interface devices 56 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.
  • 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.
  • 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).
  • ECM Electronic Control Module
  • PCM Power Control Module
  • 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.
  • OBD2 adapter 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.
  • gateway is suitable as a signal conditioning unit to use the various protocols that the car manufacturers use to operate the OBD2 interface.
  • 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.
  • 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.
  • 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.
  • the following interface devices 56 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.
  • 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 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.
  • a device 86 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 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.
  • 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
  • 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.
  • 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).
  • 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.
  • 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.
  • the front-end 7 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).
  • 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 ).
  • the front-end 7 has no way to dial directly into the Internet 19 (not shown) or in a mobile network 21 (not shown).
  • 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.
  • the smartphone 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.
  • 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:
  • Mobile modem 15 Mobile network access 20 - Mobile network 21 - Back-end 22;
  • WiFi / WLAN Interface 14 Internet Access 18 - Internet 19 - Back End 22;
  • WiFi / WLAN interface 14 Smartphone 8 - Access mobile network 20 - Mobile network
  • Bluetooth interface 17 Smartphone 8 - Access mobile network 20 - Mobile network
  • 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.
  • 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.
  • 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 Abiauf intimid 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 Abiauf intimid 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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
  • 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.
  • tank levels 113, 114 and states of charge of batteries 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.
  • 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.
  • 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).
  • 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.
  • the evaluation algorithm of the back-end 22 for this vehicle 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).
  • 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.
  • gasoline vehicles e.g. the fuel sub-types Super, Super E5, Super E10, E85 and Super Plus to choose from.
  • 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 algorithm has to identify the gas stations where fueling was done. This is done via an adjustment of the GPS coordinates 115, 116.
  • 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 ".
  • 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).
  • MJ or kWh H i energy unit
  • this value for the fuel subtype "Normal unleaded super gasoline” was around 335.9 gC0 2 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.
  • 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.
  • 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.
  • 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.
  • these raw data sets are supplemented with calculation results and stored as finished calculated data records in the vehicle 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.
  • 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.
  • the data sets of the raw data representation 200 are numbered in order to be able to determine possible manipulations.
  • the column contents in data area 102 are partially encoded.
  • 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 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.
  • 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.
  • the driver refuels id. not average fuels, but very different fuel subsets.
  • 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.
  • the algorithm can be implemented in a computer program (software).
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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”.
  • 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.
  • 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.
  • CNG fuel main CNG
  • gasoline fuel gasoline
  • other main fuel types 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 ..
  • drive systems that work with three or more fuels. The basic procedure remains the same.
  • 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),
  • 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).
  • 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.
  • 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.
  • 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.
  • 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).
  • 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
  • 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 2 / kWh H i.
  • 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 2 / kWh H i).
  • 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 2 , for the CNG leg of dataset 1658: 5.361 gC0 2 , for DS 1661: 917 gC0 2 , for DS 1664: 911 gC0 2 , 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.
  • 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 2 value per kilometer, which is entered in the additional data field 127 "gC0 2 / km" of the respective data set: 1655: 205 gC0 2 -eq / km, 1658: 197 gC0 2 -eq / km, 1661: 187 gC0 2 -eq / km, 1664: 182 gC0 2 -eq / km, 1669: 197 gC0 2 -eq / km.
  • 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.
  • 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 2 / 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 2 ) in the additional data field 126 "GHG emission amount" of refueling record 1672.
  • 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.
  • 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.
  • 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".
  • 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 2 / 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.
  • 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 2 / kWh Hi determined in step 14-A) and stores the result (70.679.11 gC0 2 ) in the data field " GHG emission quantity "of the refueling record” refueling 1672/1673 ", which was temporarily formed in the working memory.
  • 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.
  • step 17-A the algorithm adds the value (1,164.29 gC0 2 ) 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 2 , determined in step 15-A) and stores the result (71.843.40 gC0 2 ) in data field 126 "GHG emission amount" of refueling Record 1673 from.
  • 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 2 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 2 / kWh Hi ) in the additional data field 125 "life cycle emission quota" of refueling record 1673.
  • 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.
  • 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.
  • the CNG data sets 1679 (consumption 20.603 kg) and 1684 (consumption 0.413 kg) are affected.
  • 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).
  • 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.
  • 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-
  • 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.
  • step 18-A that were 249.5 gC0 2 / 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 2 / kWh H i each).
  • 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 2 and for the CNG subset of the data set 1684: 1.380 gC0 2 .
  • the algorithm writes these calculation results in the additional data field 126 "GHG emission quantity" of these data records.
  • 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 2 value per kilometer, which is entered in the additional data field 127 "gC0 2 / km" of the respective data set: 1679 : 182 gC0 2 -eq / km and 1684: 197 gC0 2 -eq / km.
  • 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.
  • 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 2 / 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 2 ) in the additional data field 126 "GHG emission amount" of refueling record 1686.
  • 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.
  • 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.
  • 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".
  • 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 2 / 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.
  • 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 2 / kWh Hi , determined in step 14-B) and stores the result (60.082,43 gC0 2 ) in the data field " GHG emission quantity "of the refueling record” refueling 1686/1687 ", which was temporarily formed in the working memory.
  • 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.
  • step 17-B the algorithm adds the value (1.616.6 gC0 2 ) 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 2 , determined in step 15-B) and stores the result (61,699.07 gC0 2 ) in data field 126 "GHG emission amount" of refueling Record 1687 from.
  • 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 2 , 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 2 / kWh H i) in the additional data field 125 "life cycle emission quota" of refueling record 1687.
  • 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.
  • 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.
  • CNG data sets 1689 (consumption 1,524 kg) and 1692 (consumption 19,167 kg) are affected.
  • the gas fuel in the tank 1 is used, which was consumed to a remainder of 0.709 kg.
  • 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).
  • 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.
  • 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 2 / 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 2 / kWh H i each).
  • 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 2 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.
  • 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 2 value per kilometer, which the algorithm enters in the additional data field 127 "gC0 2 / km" of the respective data record: 1689 : 163 gC0 2 -eq / km and 1692: 164 gC0 2 -eq / km.
  • 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.
  • 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 2 / 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 2 ) in additional data field 126 "GHG emission amount from refueling record 1695.
  • 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.
  • 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.
  • 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".
  • 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 2 / 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.
  • 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 2 / kWh Hi , determined in step 14-C) and stores the result (20.368,32 gC0 2 ) in the data field " GHG emission quantity "of the refueling record” refueling 1695/1696 ", which was temporarily formed in the working memory.
  • 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.
  • step 17-C the algorithm adds the value (2,043.83 gC0 2 ) 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 2 , determined in step 15-C) and stores the result (22,412.15 gC0 2 ) in data field 126 "GHG emission quantity" of refueling Record 1696 from.
  • step 18-C the algorithm divides the value (22,412.15 gC0 2 , 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 2 / kWh H i) in the additional data field 125 "life cycle emission quota" of refueling record 1696.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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)
  • 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 2 / kWh H i (determined in step 18-C).
  • 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 2 / kWh H i each).
  • 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 2 , 1704: 313 gC0 2 , 1707: 313 gC0 2 , 1711: 12.751 gC0 2 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.
  • 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 2 value per kilometer, the algorithm carries this value into the additional data field 127 "gC0 2 / km" of the respective data set: 1700: 68 gC0 2 -eq / km, 1704: 63 gC0 2 -eq / km, 1707: 63 gC0 2 -eq / km, 1711: 63 gC0 2 -eq / km and 1714: 63 gC0 2 eq / km.
  • 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.
  • 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 2 / 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 ( 2 557.37 gC0 2 ) in the additional data field 126 "GHG emission amount" of the refueling data record 1716.
  • 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.
  • 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.
  • 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.
  • 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".
  • 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 2 / 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.
  • 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 2 / kWh Hi determined in step 14-D) and stores the result (0.0 gC0 2 ) in the data field " GHG emission quantity "of the refueling record” Refueling 1716/1717 ", which was temporarily formed in the working memory.
  • 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.
  • step 17-D the algorithm adds the value (2,557.37 gC0 2 ) 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 2 , determined in step 15-D) and stores the result ( 2 557.37 gC0 2 ) in data field 126 "GHG emission quantity" of refueling Record 1717 from.
  • step 18-D the algorithm divides the value stored in additional data field 126 "GHG Emission Amount" of the current refueling record 1717 ( 2 557.37 gC0 2 , 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 2 / kWh H i) in the additional data field 125 "life cycle emission quota" of refueling record 1717.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 2 , 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.
  • 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 2 value per kilometer, which is entered in the additional data field 127 "gC0 2 / km" of the respective data set: 1719: 8 gC0 2 -eq / km, 1723: 8 gC0 2 -eq / km, and 1726: 8 gC0 2 -eq / km.
  • the algorithm does not calculate data for the CNG est in CNG tank 1 because there is no next CNG refueling record.
  • step 10-E the algorithm detects nothing because there are no more CNG refueling records.
  • step 11-E the algorithm calculates nothing because there are no more CNG refueling records.
  • step 12-E the algorithm calculates nothing because there are no more CNG refueling records.
  • step 13-E the algorithm calculates nothing because there are no more CNG refueling records.
  • step 14-E the algorithm calculates nothing because there are no more CNG refueling records.
  • step 15-E the algorithm calculates nothing because there are no more CNG refueling records.
  • step 16-E the algorithm calculates nothing because there are no more CNG refueling records.
  • step 17-E the algorithm calculates nothing because there are no more CNG refueling records.
  • step 18-E the algorithm calculates nothing because there are no more CNG refueling records.
  • 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).
  • CNG main fuel CNG
  • 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 2 -eq / km in step 08. Except for the GHG emission quota 127, the algorithm adds this section-specific data to CNG in step 20.
  • 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).
  • 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).
  • the algorithm 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
  • 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).
  • 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
  • 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.
  • 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.
  • 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)
  • 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 2 / kWh H i (not shown).
  • 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 2 / kWh Hi each).
  • 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 2 , for the gasoline Part of the data set 1657: 200.0 gC0 2 , for DS 1660: 182.9 gC0 2 , for DS 1663: 163.5 gC0 2 , for DS 1668: 519.2 gC0 2 , for DS 1670: 8.596.4 gC0 2 , for DS 1674: 6.2 gC0 2.
  • These calculation results are written by the algorithm in the additional data field 126 "GHG emission quantity
  • 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).
  • additional data field 121 which gives the C0 2 value per kilometer, which is entered in the additional data field 127 "gC0 2 / km" of the respective data set: 1654: 278 gC0 2 -eq / km , 1657: 250 gC0 2 -eq / km, 1660: 261 gC0 2 -eq / km, 1663: 272 gC0 2 -eq / km, 1668: 247 gC0 2 -eq / km, 1670: 239 gC0 2 -eq / km and 1674: 309 gC0 2 -eq / km.
  • 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).
  • 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 2 / 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 2 ) in the additional data field 126 "GHG emission amount" of the refueling record
  • step 29-A the algorithm determines by subtracting the data field 113 of the refueling record 1676 from the refueling record data field 113
  • 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.
  • 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.
  • 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.
  • 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 2 / 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.
  • 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 2 / kWh H i; Step 33-A) and stores the result (46,358.02 gC0 2 ) in the "GHG emission amount” data field of the refueling record "refueling 1676/1677” which is temporarily formed in the working memory.
  • 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.
  • step 36-A which corresponds to step 17-A, the algorithm adds the value (22,005 gC0 2 ) 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 2 , determined in step 34-A) and stores the result (68,363 gC0 2 ) in data field 126" GHG emission amount from refueling record 1677.
  • 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 2 , 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 2 / kWh H i) in the additional data field "life cycle emission ratio" of the refueling 125 Record 1677 from.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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 2 / kWh H i (determined in step 37-A).
  • 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 2 / kWh Hi each).
  • 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 2 , for 1680: 13.176.9 gC0 2 , for 1683: 413.4 gC0 2 , for 1688: 53.0 gC0 2 , for 1691: 379.4 gC0 2 , for 1693: 7859.9 gC0 2 , for 1697: 53.0 gC0 2 , for 1699
  • 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 2 / km" of the respective data set: 1678: 354 gC0 2 -eq / km, for 1680: 231 gC0 2 -eq / km, for 1683 : 258 GC0 2 eq / km for 1688: 354 GC0 2 eq / km for 1691: 253 GC0 2 eq / km for 1693: 231
  • 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.
  • step 29-B corresponding to step 10-E the algorithm determines nothing because there are no more gasoline refueling records.
  • step 30-B corresponding to step 11-E the algorithm calculates nothing because there are no more gasoline refueling records.
  • step 31-B corresponding to step 12-E the algorithm calculates nothing because there are no more gasoline refueling records.
  • step 32-B corresponding to step 13-E the algorithm calculates nothing because there are no more gasoline refueling records.
  • step 33-B corresponding to step 14-E the algorithm calculates nothing because there are no more gasoline refueling records.
  • step 34-B corresponding to step 15-E the algorithm calculates nothing because there are no more gasoline refueling records.
  • step 35-B corresponding to step 16-E the algorithm calculates nothing because there are no more gasoline refueling records.
  • step 36-B corresponding to step 17-E the algorithm calculates nothing because there are no more fueling records.
  • step 37-B which corresponds to step 18-E, the algorithm calculates nothing because there are no more fuel refueling records.
  • 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).
  • 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 2 -eq / km. Except for the GHG emission quota 127, the algorithm adds this segment-specific data to gasoline-specific summation values in step 39.
  • step 41 the algorithm adds the subtotals determined per fuel main type to total values.
  • 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.
  • 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.
  • the algorithm queries the corresponding (LCA) GHG emission quota value from the fuel file / database 31.
  • regular gasoline it is 335.9 gC0 2 -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 2 ) is saved for further calculations.
  • This difference is the greenhouse gas reduction performance that the vehicle 1 has provided over the distance traveled.
  • step 45 the algorithm calculates the one kilometer reference quota for the GHG emission of the vehicle 1.
  • step 47 the algorithm waits for another front end 7 to supply new records 102 for calculation.
  • the algorithm according to the invention starts again with step 1.
  • the back-end 22 is thus provided raw data sets 102.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 3 a comparison of the refueling date is made with the times at which the gas stations has changed the fuel subtype.
  • 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.
  • 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 2 -eq / kWh H i (gC0 2 -eq / MJ), but also may be indicated in gC0 2 - eq / sales unit.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 9 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).
  • 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.
  • 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 2 / km.
  • 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.
  • 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.
  • step 14 the algorithm calculates the one kilometer reference quota for the GHG emission of vehicle 1.
  • the reference emission determined in step 12 is divided by the distance traveled by vehicle 1 (determined in step 5).
  • 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.
  • the algorithm sets the difference between the one kilometer reference C0 2 emission determined in step 14 and the one kilometer C0 2 emission determined in step 11 in relation to the one kilometer determined in step 14 Reference CO 2 emission.
  • 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.
  • 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.
  • 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.
  • 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.
  • the desired result data are shown.
  • 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).
  • 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
  • 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).
  • 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.
  • the quantity of 20.916 kg refueled was composed of 80% (16.733 kg) of CNG and 20% (4.183 kg) of BioMethane.
  • the new gas mixture after the 2nd refueling was 4.183 kg (19.547%) from BioMethane and 17.217 kg (80.453%) from CNG.
  • 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.
  • 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).
  • 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 ,
  • the fuel consumptions can be determined to be specific to the type.
  • CNG fuel subspecies CNG there were at the end of the month.
  • 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.
  • the procedure for determination of composition of initial and final contents of contents of gasoline tank is basically the same.
  • 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.
  • 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 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.
  • a methane ZeroEmission energy input 154 of 12.048 kg x 13.393 kWh H i / kg 161.359 kWh H i results.
  • the volume-specific calorific value of the fuel sub-type Super E5 145 in this embodiment 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.
  • 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.
  • 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 2 -equivalent / kWh Hi , for SynMethan 141 11.9 gC0 2 -equivalent / kWh Hi and for methane ZeroEmission 142 0.0 gC0 2 --equivalent / kWh H i.
  • the (LCA) GHG emission value in this embodiment is 335.9 gC0 2 -equivalent / kWh H i, for Super E5 145 325.6 gC0 2 -Equivalent / kWh Hi , for Super E10 145 318.8 gC0 2 -equivalent / kWh Hi and for Super V-Power 147 335.9 gC0 2 -equivalent / kWh H i.
  • the total GHG emission quantity 164 is 166 of 35,276,852 gC0 2 -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 2 -eq a total of 217,361,366 gC0 2 -eq.
  • the fuel sub-type "CNG” 138 has a route-specific (LCA) GHG quota of 192.6 gC0 2 / 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 2 -eq / kWh H i (see above) Route-specific (LCA) GHG quota of 57.4 gC0 2 / km.
  • LCA route-specific
  • 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 2 -eq / kWh H i (see above ).
  • the Methane ZeroEmission fuel substandard 142 has a route-specific (LCA) GHG quota of 0.0 gC0 2 / 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 2 eq / kWh H i (see above).
  • LCA route-specific
  • the fuel sub-type "Super E5" 145 has a route-specific (LCA) GHG quota of 239.3 gC0 2 / 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 2 -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 2 / km is omitted.
  • LCA route-specific
  • 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 2 -eq / kWh H i (see above ).
  • 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 2 -eq / kWh H i (see above).
  • This total emissions divided by the total distance 134 gives the reference emission rate 188 of 258 gC0 2 / km.
  • the absolute GHG reduction performance 189 results, which in this exemplary embodiment amounts to 122 gC0 2 / 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 known energy content for CNG 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.
  • the calculated actual energy input amounts to 162, 163 but 77.2 kWh H i and 73.5 kWh H
  • 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 2 / km and for the gasoline mode with 160 gC0 2 / km assumed.
  • the emission value of 127 gC0 2 / 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 4 ), takes place in the internal combustion engine ideally according to the formula CH 4 + 20 2 >> 2H 2 0 + C0 2 .
  • Carbon (C) has the molecular mass 12 and atomic hydrogen (H) the atomic mass 1, CH 4 thus the molecular mass 16.
  • Oxygen has the molecular mass 16 and C0 2 thus the molecular mass 44.
  • CH 4 methane
  • a stoichiometric C0 2 emission of 6.8 x 2.344.5 15,942.52 gC0 2 , based on a kilometer covered by gasoline, is the official stoichiometric C0 2 -Emission rate 204 thus 159.4 gC0 2 / km.
  • the calculated actual LCA-GHG emission quotas are 177, 178 but 125.9 gC0 2 / km in CNG mode and 236.8 gC0 2 / km in gasoline mode.
  • 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.
  • NO x emissions 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 2 -eq / km and in gasoline mode a NO x emission quota 219 of 59 mg N0 2 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.
  • the route-specific NO x emission quota values 218, 219 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.
  • 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.
  • NO x emission quotas 221, 222 officially stated by the manufacturer, 30 mg NO 2 -eq / km were assumed for the CNG mode and 50 mg N0 2 -eq / km for petrol mode.
  • Absolute deviations 223, 224 of 9 mg N0 2 -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 ,
  • particulate emissions 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.
  • particulate matter Total distance 227 through the total distance 134 results in the average particulate matter emission rate 231.
  • 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.
  • 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 ,
  • 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.
  • 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.
  • 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.
  • Gateway of the host system 23 is the Gateway of the host system 23
  • Fuel database / file of the host server 24 Gas station database / file of the host server 24
  • Subsystem of the vehicle 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
  • ECM Electronic Control Module
  • PCM Power Control Module
  • ECU Electronic Control Unit
  • SAE-J1850-VPWM protocol for communication over d.
  • General interface of the front-end 7 for the connection of peripheral devices preferably an RS 232 interface with appropriate driver software
  • 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
  • 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"

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Mechanical Engineering (AREA)
  • General Engineering & Computer Science (AREA)
  • Navigation (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)
  • Control Of Vehicle Engines Or Engines For Specific Uses (AREA)
  • Electrical Control Of Air Or Fuel Supplied To Internal-Combustion Engine (AREA)
  • Measuring Volume Flow (AREA)

Abstract

L'invention concerne un procédé et un système permettant de déterminer les consommations de carburant, utilisations d'énergie et émissions réelles lors de l'utilisation quotidienne de véhicules routiers.
EP17764511.6A 2016-05-25 2017-05-24 Procédé et système permettant de déterminer les consommations de carburant, utilisations d'énergie et émissions réelles lors de l'utilisation quotidienne de véhicules routiers Withdrawn EP3465633A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP16020189 2016-05-25
PCT/EP2017/062600 WO2017202947A2 (fr) 2016-05-25 2017-05-24 Procédé et système permettant de déterminer les consommations de carburant, utilisations d'énergie et émissions réelles lors de l'utilisation quotidienne de véhicules routiers

Publications (1)

Publication Number Publication Date
EP3465633A2 true EP3465633A2 (fr) 2019-04-10

Family

ID=56117466

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17764511.6A Withdrawn EP3465633A2 (fr) 2016-05-25 2017-05-24 Procédé et système permettant de déterminer les consommations de carburant, utilisations d'énergie et émissions réelles lors de l'utilisation quotidienne de véhicules routiers

Country Status (2)

Country Link
EP (1) EP3465633A2 (fr)
WO (1) WO2017202947A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4282688A1 (fr) * 2022-05-24 2023-11-29 Floid s.r.l. Système de surveillance de paramètres relatifs à un véhicule équipé d'une interface utilisateur

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7011914B2 (ja) * 2017-09-19 2022-01-27 日本特殊陶業株式会社 微粒子検知システム
DE102018210958B4 (de) 2018-07-04 2024-04-18 Audi Ag Verfahren und Backendvorrichtung zum Einstellen eines vorbestimmten Flottenkennwerts einer Fahrzeugflotte
JP2020066390A (ja) * 2018-10-26 2020-04-30 日立オートモティブシステムズ株式会社 運転支援装置
DE102019206211A1 (de) * 2019-04-30 2020-11-05 Ford Global Technologies, Llc Computerimplementiertes Verfahren zum Bereitstellen von Daten
JP7103311B2 (ja) 2019-07-01 2022-07-20 トヨタ自動車株式会社 情報管理システム及び情報管理方法
DE102019131734A1 (de) * 2019-11-25 2021-05-27 Audi Ag Vorrichtung und verfahren zur bewertung eines fahrvorgangs
CN111750948B (zh) * 2020-06-02 2022-05-17 重庆长安汽车股份有限公司 车辆油耗计算方法及系统
DE102020129992B4 (de) 2020-11-13 2022-09-08 Volkswagen Aktiengesellschaft Verfahren zur Bestimmung eines Kraftstoffverbrauchs eines Fahrzeugs
CN112785843B (zh) * 2020-12-26 2022-03-11 清华四川能源互联网研究院 碳排放监测方法、装置、服务器和计算机可读存储介质
DE102021204469A1 (de) 2021-05-04 2022-11-10 Robert Bosch Gesellschaft mit beschränkter Haftung Vorrichtung und Verfahren zur Diagnose einer Manipulation eines Abgasstrangs einer Brennkraftmaschine
CN113724104B (zh) * 2021-11-02 2022-03-22 国网北京市电力公司 一种电力减碳量预测方法、系统、设备及介质
CN115859694B (zh) * 2023-02-27 2023-05-12 中国电子工程设计院有限公司 用于半导体制造设备的废气处理仿真模型构建方法及装置
CN117892563B (zh) * 2024-03-15 2024-05-28 中铁二十三局集团第一工程有限公司 拌合站沥青废气处理碳排放测算评价方法、系统及装置

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2131865C (fr) 1993-09-10 2000-06-13 Michael D. Jack Capteur optique pour l'analyse a distance des gaz d'echappement de voitures automobiles
DE19901915C1 (de) 1999-01-19 2000-04-20 Siemens Ag Verfahren zur katalytischen Umsetzung von im Abgas eines Verbrennungsmotors enthaltenen Stickoxiden
US7904219B1 (en) 2000-07-25 2011-03-08 Htiip, Llc Peripheral access devices and sensors for use with vehicle telematics devices and systems
US6636790B1 (en) 2000-07-25 2003-10-21 Reynolds And Reynolds Holdings, Inc. Wireless diagnostic system and method for monitoring vehicles
US6604033B1 (en) 2000-07-25 2003-08-05 Networkcar.Com Wireless diagnostic system for characterizing a vehicle's exhaust emissions
US6611740B2 (en) 2001-03-14 2003-08-26 Networkcar Internet-based vehicle-diagnostic system
US6879894B1 (en) 2001-04-30 2005-04-12 Reynolds & Reynolds Holdings, Inc. Internet-based emissions test for vehicles
US6594579B1 (en) 2001-08-06 2003-07-15 Networkcar Internet-based method for determining a vehicle's fuel efficiency
US6832141B2 (en) 2002-10-25 2004-12-14 Davis Instruments Module for monitoring vehicle operation through onboard diagnostic port
US8437903B2 (en) * 2004-11-26 2013-05-07 Lysanda Limited Vehicular diagnostic system
US20080015748A1 (en) 2006-07-14 2008-01-17 David Nagy System for monitoring, controlling, and reporting vehicle operation through onboard diagnostic port
DE102007042749A1 (de) 2007-09-07 2009-03-12 Testo Ag Verfahren und Vorrichtung zur Motorabgasmessung
DE102007057216B4 (de) 2007-11-28 2009-08-20 Enerday Gmbh System mit Fernbedienung zum ferngesteuerten Anlassen eines Antriebsmotors eines Fahrzeugs sowie entsprechendes Verfahren
DE102008005701A1 (de) 2008-01-24 2009-07-30 Volkswagen Ag Verfahren zur Erfassung des Betriebszustandes einer Brennkraftmaschine
US7886528B2 (en) 2008-02-29 2011-02-15 Perkins Engines Company Limited System for controlling exhaust aftertreatment
PL2151804T3 (pl) * 2008-07-31 2017-08-31 ARKTIK GmbH Automatyczne określanie wartości emisji dla pojazdu mechanicznego
US8285439B2 (en) 2009-04-07 2012-10-09 Ford Global Technologies, Llc System and method for performing vehicle diagnostics
DE102010003382B4 (de) 2010-03-29 2014-07-17 Faktorplus Green Technology Gmbh Verfahren zum Emissionsmindern von Verbrennungskraftmaschinen und Verbrennungskraftmaschine
DE102011076638A1 (de) 2011-05-27 2012-11-29 Stephan Kaufmann Verfahren zur Fahrzeugkommunikation über ein fahrzeugimplementiertes Fahrzeugdiagnosesystem, Schnittstellenmodul sowie Fahrzeugdiagnose-Schnittstelle und Diagnose- und Steuerungsnetz für eine Vielzahl von Fahrzeugen
WO2013072939A1 (fr) * 2011-11-08 2013-05-23 Logica Private Limited Dispositif de calcul de la consommation de carburant pour véhicules à moteur à combustion interne
DE102012206457A1 (de) 2012-04-19 2013-10-24 Faktorplus Green Technology Gmbh Verfahren zur Emissionsreduktion

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4282688A1 (fr) * 2022-05-24 2023-11-29 Floid s.r.l. Système de surveillance de paramètres relatifs à un véhicule équipé d'une interface utilisateur

Also Published As

Publication number Publication date
WO2017202947A3 (fr) 2018-03-08
WO2017202947A2 (fr) 2017-11-30

Similar Documents

Publication Publication Date Title
EP3465633A2 (fr) Procédé et système permettant de déterminer les consommations de carburant, utilisations d'énergie et émissions réelles lors de l'utilisation quotidienne de véhicules routiers
CN101968635B (zh) 一种在用汽车油耗实时测量监控系统及其测量监控方法
Joumard Methods of estimation of atmospheric emissions from transport: European scientist network and scientific state-of-the art
EP2560146A1 (fr) Système et procédé de visualisation de données de géoposition et de diagnostic de véhicule
Guillou et al. Fuel consumption testing to verify the effect of tire rolling resistance on fuel economy
DE102012217911A1 (de) Beschaffung von Daten von Sensoren im Fahrzeug und Vorlegen vereinigter gemittelter Leistungsindikatoren
DE102017215054A1 (de) Verfahren, System und mobiles Anwendergerät zur Anpassung eines Energieverwertungsvorgangs eines Fahrzeugs
Forkenbrock Implementing a mileage-based road user charge
DE102019203275A1 (de) Verfahren zur Überwachung von Emissionen einer Fahrzeugflotte
DE102016206802A1 (de) Verfahren, Vorrichtung und mobiles Anwendergerät zur Anpassung einer Energieversorgung eines Antriebssystems eines Fahrzeugs
JP2020086610A (ja) サーバ装置および情報提供方法
KR20110078352A (ko) 도로 및 교통수단별 온실가스와 대기오염물질의 배출계수 실험을 위한 관련인자 및 대표 주행모드 개발 시스템
Ivanič Data collection and development of New York City refuse truck duty cycle
DE102016206800A1 (de) Verfahren, Vorrichtung und mobiles Anwendergerät zur Anpassung einer Energieversorgung eines Antriebssystems eines Fahrzeugs
DE102012220673A1 (de) Elektronisches Vergleichssystem von Werten des durchschnittlichen Kraftstoffverbrauchs und der Menge eines Schadgases, das von einem entsprechenden Kraftfahrzeug ausgestoßen wird, und zugeordnetes Vergleichsverfahren
Walkowicz et al. Coca-Cola refreshments class 8 diesel electric hybrid tractor evaluation: 13-month final report
DE102020213402A1 (de) Verfahren zum Ermitteln des Verbrauchs einer Fahrzeugflotte aus Kraftfahrzeugen an einem Energieträger und/ oder an elektrischer Energie, sowie System hierzu
Posada et al. Measuring in-use fuel economy in Europe and the US: Summary of pilot studies
DE102011102913A1 (de) Vorrichtung und Verfahren zur Ermittlung von Kosten für eine an einer Energieabgabestelle von einem Kraftfahrzeug aufgenommene Energiemenge
DE102014015872A1 (de) Entnahmevorrichtung für ein gasförmiges Brennmittel zum Betanken eines Kraftfahrzeugs mit komprimiertem gasförmigem Brennmittel
DE102009000466A1 (de) Gerät für die automatische Abrechnung in einem Gebührenerhebungs- oder Mautsystem
North et al. Development of a vehicle emissions monitoring system
Reyes Campaña et al. Public transportation in the DMQ by geography and incidence.
Cadle et al. Real-world vehicle emissions: a summary of the tenth coordinating research council on-road vehicle emissions workshop
Ramírez et al. Aggregated Metrics to Assess Fuel Consumption in Freight Fleets

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20181218

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20210504

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20211116