[go: up one dir, main page]

WO2024258680A1 - Calcul et rapport de données d'émissions - Google Patents

Calcul et rapport de données d'émissions Download PDF

Info

Publication number
WO2024258680A1
WO2024258680A1 PCT/US2024/032408 US2024032408W WO2024258680A1 WO 2024258680 A1 WO2024258680 A1 WO 2024258680A1 US 2024032408 W US2024032408 W US 2024032408W WO 2024258680 A1 WO2024258680 A1 WO 2024258680A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
vehicle
fuel
emissions
values
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.)
Pending
Application number
PCT/US2024/032408
Other languages
English (en)
Inventor
Celine M. King
Richard HYMAN
Wilson Alexei
John Sattari
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.)
Greenirr Inc
Original Assignee
Greenirr Inc
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
Priority claimed from US18/394,451 external-priority patent/US12469338B2/en
Application filed by Greenirr Inc filed Critical Greenirr Inc
Publication of WO2024258680A1 publication Critical patent/WO2024258680A1/fr
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • the disclosure features a method for monitoring emissions for one or more vehicles.
  • the method includes receiving vehicle telematics data for the one or more vehicles and receiving fuel purchase data for the one or more vehicles. Then the vehicle telematics data and the fuel purchase data are formatted in alignment with a data structure schema, and stored in a data structure.
  • the method further includes determining whether one of the vehicle telematics data or the fuel purchase data contains sufficient information to determine an amount of emissions generated by the vehicle(s) over a particular period of time. Then, in response to determining that one of the vehicle telematics data or the fuel purchase data does not contain sufficient information to determine the emissions generated by the vehicle(s) over a particular period of time, utilizing, at least a portion of the other of the vehicle telematics data or the fuel purchase data to determine the emissions generated by the vehicle(s) over a particular period of time. [0005] In other aspects of the disclosure, one or more of the following features may be included.
  • the vehicle telematics data may comprise one or more of the data elements: distance traveled; odometer reading; idle time; and fuel consumption; and the fuel purchase data comprises one or more of the data elements: fuel purchase amount; fuel type; fuel cost; location of purchase; mileage; and date of purchase.
  • the method may further comprise determining whether the distance traveled data element contains more than a threshold number of null values and, if so, completing an action selected from: substituting distance traveled data values with odometer reading data values; substituting distance traveled data values with mileage data values; or removing the distance data element from utilization in determining the emissions generated by the vehicle(s).
  • the method may further comprise determining whether the fuel consumption data element contains more than a threshold number of null values and, if so, completing an action selected from: substituting fuel consumption data values with fuel purchase amount data values; or imputing fuel consumption data values in place of the null values.
  • the vehicle telematics data and the fuel purchase data may each come from either a fleet management system or a fuel card system.
  • the method may further comprise generating an emissions forecast based at least in part on a trend derived from historical data of vehicle emissions.
  • the method may comprise calculating scope 1, scope 2, and scope 3 emissions associated with the one or more vehicles.
  • a method for providing accurate and reliable emissions monitoring comprises receiving vehicle telematics data for one or more vehicles and receiving fuel purchase data for the vehicle(s). Then formatting the vehicle telematics data and the fuel purchase data in alignment with a data structure schema, storing the vehicle telematics data and the fuel purchase data in a data structure and assessing the vehicle telematics data and the fuel purchase data for null values. The method then includes determining whether to utilize the vehicle telematics data, the fuel purchase data, or both, based at least in part on the assessment of null values, to calculate emissions generated by the vehicle(s) within a timeframe, and calculating emissions generated by the vehicle(s) within the timeframe.
  • FIG.1 is a diagram of onboard vehicle modules and a telematics control unit.
  • FIG.2 is a diagram of a fuel card system.
  • FIG.3 is an overall data flow diagram.
  • FIG.4 is a data flow diagram within an emissions calculation and prediction system.
  • FIG.5 is an example of a hardware diagram of an emissions calculation and prediction system.
  • FIG.6 is an example of a data acceptance methodology.
  • FIG.7 is an example of a logic flow diagram.
  • FIG.8 is an example of an emissions data visualization chart.
  • FIG.9 is an example of an emissions forecasting chart.
  • FIG.10 is an example of a visualization of a list of highest emitting vehicles.
  • FIG.11 is an example of a visualization of a cost of carbon calculation.
  • Systems are described herein that are capable of receiving data from disparate sources (e.g., a vehicle telematics system and a fuel card system), and extracting, parsing, cleaning, transforming, processing, and storing the data, as well as calculating emissions generated by a source (e.g., a truck or a fleet of trucks) and generating emissions reports and forecasts based on the data and calculated emissions.
  • the systems may provide the data, calculated emissions, emissions reports, emissions forecasts, and other information, to a user, e.g., through a user portal that communicates with a system API.
  • the systems may enable users (e.g., trucking fleet managers) to accurately and conveniently monitor their past, present, and expected future greenhouse gas (GHG) (or other pollutants) emissions (including scope 1, 2, and 3 emissions) and provide that emissions data to environmental regulators, upstream shippers, and other stakeholders, and/or to make equipment, process, or personnel changes to reduce their emissions output.
  • GOG greenhouse gas
  • a system may receive data from a vehicle’s telematics control unit (TCU), such as fuel consumption data, distance traveled data, idle time data, etc.
  • TCU telematics control unit
  • the system may also receive data from a fuel card system, which tracks fuel purchases associated with a particular user or group of users.
  • the system may process and organize this data, and use it to calculate emissions from the vehicle generated over a period of time.
  • the system may analyze both the data coming from the TCU and the data coming from the fuel card system for completeness and reliability, including identifying null values and errors. After analyzing the data, the system may discard erroneous values, and may discard null values or substitute or impute values in their place. Depending on data availability, completeness, reliability, and other factors, the system may choose to use either the TCU data, the fuel card data, or both, to calculate the emissions from the vehicle. The system may also cross-validate the TCU data with the fuel card data.
  • the system may also analyze and process the calculated emissions in order to, for example, identify trends, predict future emissions, identify potential emissions reduction options, calculate the cost of emissions, allocate emissions to specific trips, loads, or shippers, generate other insights, and generate reports for a user.
  • the phrases “period of time” and “timeframe” encompass both past and present (i.e., real-time).
  • Some additional information may be found in the following references, the entireties of which are hereby incorporated by reference: Cho et al. International Journal of Automotive Technology, Vol.7, No.4, pp. 509 ⁇ 517 (2006). Cassias and Kun, “Vehicle telematics: A literature review,” Univ.
  • FIG.1 shows an example of a vehicle 100, which comprises a number of onboard vehicle modules 102 and a Telematics Control Unit (TCU) 116.
  • TCU Telematics Control Unit
  • the vehicle 100 may be a truck, car, van, motorcycle, train, airplane, helicopter, or other type of machine capable of transport.
  • the onboard vehicle modules 102 may comprise, for example, a GPS (or other GNSS) unit 104, a fuel sensor 106, a load sensor 108, an on-board diagnostics module 110, an engine control unit 112, and an odometer 114.
  • the onboard vehicle modules 102 may, among other functions, collect data pertaining to the vehicle’s operation, including, for example, distance traveled, odometer reading, freight transported, idle time (including short idle time, inter-trip idle time, and parked idle time), fuel consumption, fuel level, MPG (and/or MPGEUS [Miles Per Gallon electric Equivalent]), Kilowatt Hours, and the Vehicle ID. There may be more, fewer, or different onboard vehicle modules 102.
  • the TCU 116 manages the collection and transmission of vehicle information (e.g., data collected by the onboard vehicle modules 102).
  • the TCU 116 may receive data from the onboard vehicle modules 102 through a communication mode 130, such as a Controller Area Network (CAN) bus.
  • CAN Controller Area Network
  • the TCU 116 may comprise a number of modules including, for example, a General Packet Radio Service (GPRS) communications module 118, an engine controller 120, an external interface 122, a memory 124, a processor 126, and a transceiver 128.
  • GPRS General Packet Radio Service
  • a GPS (or other GNSS) unit may be included in the TCU 116 instead of, or in addition to, an onboard vehicle GPS unit 104.
  • the GPRS communications module 118 may enable data connectivity to remote devices over a wireless or cellular network or satellite.
  • the GPS unit 104 may communicate with satellites using the GPRS communications module 118 or via another known means.
  • the engine controller 120 may receive data from and issue instructions to the engine control unit 112.
  • the external interface 122 may enable the TCU 116 to receive instructions (e.g.
  • the TCU 116 may comprise physical hardware components such as memory 124 (which may be volatile memory and/or non-volatile memory), a processor 126 (which may include one or more processors), and a transceiver 128, which may enable the TCU 116 to send and receive data. There may be more, fewer, or different modules and hardware components within the TCU 116.
  • FIG.2 shows an example of a Fuel Card System (FCS) 200.
  • the FCS 200 may typically comprise a fuel pump 202, which delivers fuel (gasoline, diesel, electric power, etc.) to the vehicle 100, a card reader 204, and a communications module 206.
  • the vehicle driver 208 will utilize a fuel card 210, (which may be a credit card, debit card, or other method of payment, such as a smartphone with NFC, and which may be associated with a user, a vehicle, a group of users, a group of vehicles, a user and a vehicle, a group of users and a group of vehicles, a fleet, a company, etc.) to purchase fuel.
  • the vehicle driver 208 will, e.g., swipe, insert, or tap the fuel card 210 at the FCS 200 through the card reader 204.
  • the card 210 will be authenticated by the card reader 204, which collects and exchanges information regarding the transaction.
  • the card reader 204 may decode the card’s information and encrypt it for transmission via the communications module 206.
  • the communications module may send the card’s information and the transaction information to a payment processor, which may further communicate with the cardholder’s bank or credit agency for verification.
  • the communications module 206 may receive the verification and send it to the card reader 204 for display to the driver 208.
  • the driver 208 may be required to enter a unique code, e.g. into the card reader 204 or into a mobile application, to identify the vehicle 100.
  • the driver 208 may be required to enter the vehicle 100’s odometer value at the time of purchase.
  • the unique code and/or vehicle odometer value may, along with transaction data collected by the card reader 204, such as fuel type, fuel cost, fuel quantity purchased, driver 208 ID, vehicle 100 ID, carrier ID, date + time, location of purchase, etc., be transmitted by the communications module 206 over a wireless or wired communication network to a server belonging to the provider of the fuel card 210.
  • the provider of the fuel card may make this data accessible through, e.g., an API (Application Programming Interface).
  • Fig.3 shows a simplified overview of an emissions data flow, including an emissions calculation and prediction system 300 (hereinafter “the system”).
  • the TCU 116 of vehicle 100 may output vehicle information 302 collected by the onboard vehicle modules 102.
  • Vehicle information 302 may comprise data pertaining to the vehicle’s operation, including, for example, distance traveled, odometer reading, freight transported, idle time (including short idle time, inter-trip idle time, and parked idle time), fuel consumption, fuel level, MPG (and/or MPGEUS), Kilowatt Hours, and the Vehicle ID.
  • the vehicle information 302 is then received by the system 300.
  • the Fuel Card System 200 may output fuel purchase information 304 associated with the vehicle 100, including, for example, fuel quantity, fuel type (gasoline, diesel, electric power, octane rating, etc.), fuel price, date and time of purchase, fuel card ID, vehicle ID, and odometer reading at time of purchase.
  • the fuel purchase information 304 is then received by the system 300.
  • the system 300 may then ingest, parse, process, and store the vehicle information 302 and the fuel purchase information 304.
  • the system 300 may use the information 302 and/or 304 to calculate emissions created by the operation of the vehicle 100 (or otherwise associated with the vehicle 100).
  • the system 300 may also generate predicted future emissions, emissions trends, emissions reduction recommendations, emissions reports, and other insights based upon the vehicle information 302 and/or the fuel purchase information 304.
  • the calculated emissions and generated insights may collectively be referred to as output data 306.
  • the output data 306 may be received by a user device 308 (such as a computer, mobile device, server, etc.).
  • the user device 308 may request the data from the system 300 through an API.
  • FIG.4 shows a diagram of a data flow 400 that occurs within the system 300.
  • the data flow 400 may comprise three main layers—extraction layer 416, storage & processing layer 418, and API layer 420.
  • the extraction layer may comprise the data ingestion stage 402, the initial data storage stage 404, and the data parsing stage 406.
  • the storage and processing layer 418 may comprise the intermediate storage stage 408, the data processing stage 410, and the database stage 412.
  • the API layer may comprise the API gateway server stage 414.
  • the system receives data, such as the vehicle information 302 and/or the fuel purchase information 304.
  • the system may receive data from external API’s or data stores from data providers such as fleet management systems like EFS, Omnitracs, Geotab, VerizonConnect etc.
  • a Fuel Card System provider may provide access to an API, from which the system 300 can request the fuel purchase information 304
  • a telematics provider may provide access to an API, from which the system 300 can request the vehicle information 302.
  • the information may be specific to a vehicle 100, a driver 208, a fleet of vehicles, a group of drivers, an entire company, a group of companies, etc., and may be associated with one or more unique ID’s, and may have parent-child associations, such as emissions associated with a vehicle, which is associated with a fleet, which is associated with a company.
  • the information may also be received via other means.
  • each data source may have an associated integration based upon the characteristics of the data source.
  • These integrations may, for example, be housed within a server, such as an AWS (Amazon Web Services) EC2 (Elastic Compute Cloud) instance, and may function to extract data from the data source, format the extracted data into an acceptable format for the initial data storage 404, and send the extracted data to the initial data storage 404.
  • AWS Amazon Web Services
  • EC2 Elastic Compute Cloud
  • the initial data storage 404 may be any type of data structure including, for example, a queue, and in particular, an internal messaging queue.
  • the initial data storage 404 may store data that has been ingested at stage 402 in an organized manner, such as messages in the internal messaging queue, to prepare the data for data parsing at stage 406.
  • the initially stored data is parsed and formatted, for example, into individual JSON files in alignment with a desired schema. and then sent to intermediate storage 408.
  • the intermediate storage 408 may be any data structure including, for example, Amazon S3 (Simple Storage Service) buckets.
  • the data may be programmatically organized (such as by AWS Glue Jobs, e.g., into a folder structure based on ‘tablename’, ‘custom_identifier’ [e.g., vehicle ID, fleet ID, customer ID, etc.], ‘year’, ‘month’, ‘date,) and may be stored prior to further processing at stage 410.
  • the data may be encrypted, with access to certain data limited to appropriately credentialed users.
  • the system 300 may perform a variety of functions including, for example, data type transformation, data cleaning, data acceptance, unit conversion, emissions calculation, emissions forecasting, emissions analysis, recommendation generation, allocation of emissions to particular loads, shippers, and/or geographical regions, and report generation.
  • the processed data (and optionally the raw pre-processed data) may be stored in the database 412.
  • the database 412 may comprise an Amazon Relational Database Service (RDS) or other known method of storing data.
  • the database 412 may additionally include secondary storage for backend access and monitoring, such as Amazon Athena, which may help avoid database request backlogs when data is being accessed by both a customer and someone other than a customer (such as a backend developer).
  • RDS Amazon Relational Database Service
  • the database 412 may additionally include secondary storage for backend access and monitoring, such as Amazon Athena, which may help avoid database request backlogs when data is being accessed by both a customer and someone other than a customer (such as a backend developer).
  • Amazon Athena As shown by the double-sided arrow between stages 410 and 412, data within the database 412 may also be accessed for further data processing 410 if such processing is needed.
  • the further processed data may then be stored in the database 412.
  • data from the TCU 116, the FCS 200, or both may be cleaned and accepted (see FIG.6 for more detail), and the cleaned and accepted data may be stored in a table within database 412. Then, at a later point, the cleaned and accepted data may be pulled from database 412 back into data processing 410, wherein emission calculation 618 is performed by the system 300. The output of emission calculation 618 may then be stored in a different table (or tables, or other data structures and file types) within database 412.
  • Data, at any or all points during data flow 400 may be associated with a Telematics ID, or a Fuel Card ID, and/or a Vehicle ID, and/or a Customer ID.
  • the Telematics ID may be a unique identifier for the telematics data provider.
  • the Fuel Card ID may be a unique identifier for the fuel card data provider.
  • the Vehicle ID may be a unique identifier that associates data with a particular vehicle 100.
  • the Customer ID may be a unique identifier given to a customer when they subscribe to receive the services of the system 300, and the Customer ID may, for example, identify data from vehicles 100 within a fleet owned by the customer, or drivers 208 employed by the customer. These ID’s enable data organization and tracking, so that data is not inadvertently mixed up, and so that analysis can be accurately performed. [0037] At the next stage, the data may be requested from the database 412 by the API gateway server 414.
  • the API gateway server may function to receive data access requests, over a network, by customers using user devices 308.
  • the API gateway server may receive customer requests, make queries to the database 412 in response to the customer requests, and perform transformations to put the queried data into a presentable format for the frontend to display on the customer devices 308, wherein this formatted queried data may be the output data 306.
  • Non-limiting examples of formatted output data 306 are shown in FIGS.8- 11.
  • FIG.5 an example computer system 500 is shown.
  • the computer system 500 as illustrated in FIG.5 may incorporate as part of the previously described computer devices, including the system 300.
  • FIG.5 provides a schematic illustration of one embodiment of the computer system 500 that can perform the methods provided by various other embodiments, as described herein, and/or can function as the host computer system, or other networked computer system.
  • the computer system 500 may be included in a cloud environment such as the Amazon AWS platform and the operations and function described herein may be distributed over different computer systems 500 operating in different locations.
  • FIG.5 is meant only to provide a generalized illustration of various components, and or all of which may be utilized as appropriate.
  • the computer system 500 is shown comprising hardware elements that can be electrically coupled via a bus 502 (or may otherwise be in communication, as appropriate).
  • the bus 502 may be configured as one or more communication channels in a cloud-computing environment.
  • the hardware elements may include one or more processors 504, including without limitation one or more general-purpose processors and/or one or more special-purpose processors (such as digital signal processing chips, graphics acceleration processors, and/or the like); one or more input devices 508, which can include without limitation a mouse, a keyboard, a touchscreen and/or the like; and one or more output devices 510, which can include without limitation a display device, a printer and/or the like.
  • the computer system 500 may further include (and/or be in communication with) one or more non-transitory storage devices 506, which can comprise, without limitation, local and/or network accessible storage, and/or can included, without limitation, a disk drive, a drive array, an optical storage device, solid-state storage device such as random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash- updateable and/or the like.
  • non-transitory storage devices 506 can comprise, without limitation, local and/or network accessible storage, and/or can included, without limitation, a disk drive, a drive array, an optical storage device, solid-state storage device such as random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash- updateable and/or the like.
  • RAM random access memory
  • ROM read-only memory
  • Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like.
  • the computer system 500 might also include a communications subsystem 512, which can include without limitation a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device and/or chipset (such as a Bluetooth® device, an 802.11 device, a WiFi device, a WiMax device, cellular communication facilities, etc.), and/or the like.
  • the communications subsystem 512 may permit data to be exchanged with a network (such as the network described below, to name one example), other computer systems, and/or any other devices described herein.
  • the computer system 500 will further comprise a working memory 514, which can include a RAM or ROM device, as described above.
  • the computer system 500 also can comprise software elements, shown as being currently located within the working memory 514, including an operating system 516, device drivers, executable libraries, and/or other code, such as one or more application programs 520, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein.
  • application programs 520 may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein.
  • code and/or instructions can be used to configure and/or adapt a general purpose computer (or other device) to perform one or more operations in accordance with the described methods.
  • the working memory may include one or more application programming interfaces (APIs) 518 configured to send and receive data and instructions to and from other networked stations.
  • APIs application programming interfaces
  • the API(s) 518 may be an example of an API on an API gateway server 414.
  • a set of these instructions and/or code might be stored on a computer-readable storage medium, such as the storage device(s) 506 described above. In some cases, the storage medium might be incorporated within a computer system, such as the computer system 500.
  • the storage medium might be separate from a computer system (e.g., a removable medium, such as a compact disc), and/or provided in an installation package, such that the storage medium can be used to program, configure and/or adapt a general purpose computer with the instructions/code stored thereon.
  • These instructions might take the form of executable code, which is executable by the computer system 500 and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system 500 (e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.) then takes the form of executable code.
  • some embodiments may employ a computer system (such as the computer system 500) to perform methods in accordance with various embodiments of the disclosure. According to a set of embodiments, some or all of the procedures of such methods are performed by the computer system 500 in response to processor 504 executing one or more sequences of one or more instructions (which might be incorporated into the operating system 516 and/or other code, such as an application program 520) contained in the working memory 514.
  • a computer system such as the computer system 500
  • processor 504 executing one or more sequences of one or more instructions (which might be incorporated into the operating system 516 and/or other code, such as an application program 520) contained in the working memory 514.
  • Such instructions may be read into the working memory 514 from another computer-readable medium, such as one or more of the storage device(s) 506.
  • execution of the sequences of instructions contained in the working memory 514 might cause the processor(s) 504 to perform one or more procedures of the methods described herein.
  • the terms “machine-readable medium” and “computer-readable medium,” as used herein, refer to any medium that participates in providing data that causes a machine to operate in a specific fashion.
  • various computer-readable media might be involved in providing instructions/code to processor(s) 504 for execution and/or might be used to store and/or carry such instructions/code (e.g., as signals).
  • a computer-readable medium is a physical and/or tangible storage medium. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media.
  • Non-volatile media include, for example, optical and/or magnetic disks, such as the storage device(s) 506.
  • Volatile media include, without limitation, dynamic memory, such as the working memory 514.
  • Transmission media include, without limitation, coaxial cables, copper wire and fiber optics, including the wires that comprise the bus 502, as well as the various components of the communication subsystem 512 (and/or the media by which the communications subsystem 512 provides communication with other devices).
  • Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to the processor(s) 504 for execution.
  • the instructions may initially be carried on a magnetic disk and/or optical disc of a remote computer.
  • a remote computer might load the instructions into its dynamic memory and send the instructions as signals over a transmission medium to be received and/or executed by the computer system 500.
  • the communications subsystem 512 (and/or components thereof) generally will receive the signals, and the bus 502 then might carry the signals (and/or the data, instructions, etc. carried by the signals) to the working memory 514, from which the processor(s) 504 retrieves and executes the instructions.
  • FIG.6 shows an example of a data acceptance methodology, which may be used by the system 300 within, for example, the extraction layer 416 and the storage & processing layer 418.
  • data may originate from a Fuel Card System (“fuel card data”), and/or a vehicle 100’s TCU 116 (“telematic data”).
  • the system 300 may determine, prior to stage 602, whether the current set of data associated with a user/customer contains telematic data, fuel card data, both, or neither.
  • the system 300 may generate an error message to output to user devices 308 if the user devices make a request for data that is unavailable.
  • Both or either of the fuel card data and the telematic data may be missing, partial, or complete, and either may contain errors such as erroneous data, corrupted data, duplicate data, and other such errors.
  • Data may be incomplete due to system errors, downtime, or technical failure. Incomplete data may result in unaccounted periods of time that span days or weeks in which installed devices (such as a TCU 116) fail to record vehicle information relied on for emission calculations.
  • the quality of the data if not cleaned and accepted, can have a significant impact on the results of the emissions calculations and the output information 306.
  • the data acceptance methodology 600 may reduce or prevent the impact of data errors causing flawed emissions calculation results.
  • the fuel card data may include, for example, the following data elements: fuel purchase amount (gallons, kWh, etc.); fuel cost; fuel type; mileage (odometer reading at current purchase minus odometer reading at previous purchase); end date odometer reading (recorded at the end of a specific period or trip); location of purchase; vehicle ID; date; time; fleet ID; and company ID.
  • the telematic data may include, for example, the following data elements: distance traveled; odometer reading; inter-trip idle time; short idle time; parked idle time; fuel consumption; fuel consumption during idle time; fuel consumption during parked idle time; fuel tank current level; fuel type; end date odometer reading; end date odometer reading datetime; MPGEUS; kilowatt hours consumed; and vehicle ID.
  • data elements There may be more or fewer data elements in either or both sets of data.
  • Each data element may contain one or more values.
  • data elements may have values associated with a particular date and/or time, such that data collected over time can be used to determine and display trends, such as fuel consumption over time.
  • the data received by the system 300 may be received with the data elements contained therein being a variety of datatypes, including, for example, strings, integers, floats, Booleans, datetimes, etc. Some of these datatypes may be undesirable for further processing, so the system 300 will perform data type conversion 602.
  • the system 300 may implement rules such that if the fuel card data elements: fuel purchased; fuel consumed; mileage; and location of purchase; are not integers, then the system 300 will convert them to integers.
  • these fuel card data elements may be converted to floats.
  • the system 300 may implement rules such that if the telematic data elements: distance; odometer; idle time; fuel consumption; fuel tank; MPGEUS; and kilowatt hours; are not integers, then the system 300 will convert them to integers. In a similar example, these telematic data elements may be converted to floats. In another example, if date and time related data elements are not in the datetime datatype, they may be converted to the datetime datatype. Other datatype conversions may also occur during the data type conversion 602. During data type conversion 602, units of data values may be normalized to facilitate subsequent analysis.
  • the system 300 may initiate one of the data cleaning methods 604, 606, and 608, depending on the availability of fuel card data and telematic data. If fuel card data is available and telematic data is not available, then the system 300 will initiate cleaning fuel card (FC) data 604. If telematic data is available and fuel card data is not available, then the system 300 will initiate cleaning telematic data 606. If both fuel card data and telematic data are available (at least in part), then the system 300 will initiate cleaning telematic & fuel card data 608. [0053] While cleaning FC data 604, the system 300 may test, for example and without limitation, the fuel purchase amount and mileage data elements against a set of parameters.
  • FC fuel card
  • Those parameters may be, for example: upper and lower bounds (which may be based upon industry average ranges, physical limitations, etc.); duplicate value (e.g., a copy or partial record of the same value is recorded in the same index, or two attributes contain the same values in the same index); lexical errors (which may be tested for by identifying a sequence of characters that does not match the pattern of any token, including, e.g., exceeding the length of numeric constants or identifiers, the presence of illegal characters, or spelling error); cryptic errors (e.g., error codes that offer no useful information); and embedded values (values contained within or associated with other data attributes).
  • upper and lower bounds which may be based upon industry average ranges, physical limitations, etc.
  • duplicate value e.g., a copy or partial record of the same value is recorded in the same index, or two attributes contain the same values in the same index
  • lexical errors which may be tested for by identifying a sequence of characters that does not match the pattern of any token, including,
  • the system 300 may remove those values and/or data elements.
  • a driver 208 may manually enter an odometer value into the FCS 200, but make an error while doing so, resulting in a mileage calculation that is impossible, e.g., negative. Removing such erroneous numbers is necessary to avoid emissions calculations that are inaccurate.
  • the system 300 may test, for example and without limitation, the fuel consumption, distance, idle time, idle time fuel consumption, parked idle time fuel consumption, and MPGEUS data elements against a set of parameters.
  • Those parameters may be, for example: upper and lower bounds (which may be based upon industry average ranges, physical limitations, etc.); duplicate value (e.g., a copy or partial record of the same value is recorded in the same index, or two attributes contain the same values in the same index); lexical errors (which may be tested for by identifying a sequence of characters that does not match the pattern of any token, including, e.g., exceeding the length of numeric constants or identifiers, the presence of illegal characters, or spelling error); cryptic errors (e.g., error codes that offer no useful information); and embedded values (values contained within or associated with other data attributes). If the system 300 determines that the values within the data elements fail against the tested parameters (e.g.
  • the system 300 may remove those values and/or data elements.
  • the system 300 may implement both cleaning FC data 604 and cleaning telematic data 606 in combination.
  • the system 300 may initiate one of the data acceptance methods 610, 612, and 614, depending on the availability of fuel card data and telematic data. If fuel card data is available and telematic data is not available, then the system 300 will initiate accepting FC values 610. If telematic data is available and fuel card data is not available, then the system 300 will initiate accepting telematic values 612.
  • the system 300 will initiate accepting telematic & FC values 614.
  • the system 300 may evaluate the completeness of the cleaned FC data, and make decisions of whether to impute values or remove data elements and/or values. For example, the system 300 may evaluate whether the fuel purchase quantity data element contains more than a threshold number of null values (including values missing due to their removing during stage 604), and, if so, impute one or more fuel purchase quantity values.
  • the imputation of values may be based on an identified data trend and interpolated, based on an average (mean, median, or mode) value, based on an industry or company standard value, etc.
  • the system 300 may evaluate whether the mileage data element contains more than a threshold number of null values, and, if so, remove the mileage data element and use only fuel purchase quantity data for emissions calculations. [0058] While in the process of accepting telematic values 612, the system 300 may evaluate the completeness of the cleaned telematic data and make decisions of whether to impute values or remove data elements and/or values. For example, the system 300 may evaluate whether the fuel consumption data element contains for than a threshold number of null values, and, if so, impute one or more fuel consumption values. The imputation of values may be based on an identified data trend and interpolated, based on an average (mean, median, or mode) value, based on an industry or company standard value, etc.
  • the system 300 may evaluate whether the distance traveled data element contains more than a threshold number of null values, and if so, may instead determine distance based on odometer values (i.e. subtracting the earliest odometer reading within the relevant timeframe from the latest odometer reading within the relevant timeframe), or may remove the distance data element and use only fuel consumption data for emissions calculations.
  • a TCU 116 may record a distance traveled value that is physically impossible, such as 80,000 miles in one day. Removing such erroneous numbers is necessary to avoid emissions calculations that are inaccurate.
  • the system 300 may evaluate the completeness of the cleaned telematic data and cleaned FC data, and make decisions of whether to use one data source over another, to impute values, or remove data elements and/or values. For example, the system 300 may evaluate whether the fuel consumption data element (from the telematic data) contains more than a threshold number of null values, and if so, may substitute fuel purchase data from the fuel card data, if the fuel purchase data is available. If fuel purchase data is not available, or if substituting fuel purchase data will not reduce the number of null values below the threshold, then the fuel consumption data may be imputed.
  • the imputation of values may be based on an identified data trend and interpolated, based on an average (mean, median, or mode) value, based on an industry or company standard value, based on a regression, etc.
  • the system 300 may evaluate whether the distance data element contains more than a threshold number of null values. If so, the system 300 may determine distance based on odometer values (i.e. subtracting the earliest odometer reading within the relevant timeframe from the latest odometer reading within the relevant timeframe), if available, or the system 300 may substitute mileage data from the fuel card data, if the mileage data is available.
  • the system 300 may remove the distance data element and use only fuel consumption and/or fuel purchase data for emissions calculations.
  • the system 300 may use either telematics data 302 or fuel card data 304 as the primary (default) data source, and only supplement from the other data source when there are sufficient null values present.
  • some calculations may require a data element that is only sourced from one of the data sources, such as Cost of Carbon, which requires fuel cost information.
  • the system 300 may also cross-validate the telematic data with the fuel card data, using the one data source to help identify outlier values in the other.
  • the system 300 may compare the outlier data point with a comparable data point taken from the other data source. If the comparable data point conflicts with the outlier data point while matching with the identified trend, the system 300 may discard the outlier data point and substitute the comparable data point.
  • the threshold number of null values used in the data acceptance methods 610, 612, 614 may be any number, including 1, 2, 5, 10, 25, 50, 75, 100, 250, 500, 1000, 5000, 10,000, or more, or any number in between.
  • the threshold number may also be a percentage of the total expected values (wherein the number of expected values is based on a timeframe of data collection), such as 1%, 2%, 5%, 10%, 25%, 30%, 33%, 50% 67%, 75%, or 90%, or any number in between.
  • the system 300 may evaluate whether at least 10% of the expected number of fuel consumption values are null, and if so, the system 300 may impute values in place of the null values.
  • more data elements may be evaluated for null values than just those listed in examples above, and imputations, substitutions, and data element removals may be performed by the system 300 in response to such evaluations.
  • the system 300 finds, of the fuel consumption values derived from the telematics system, that more than a threshold percentage of null values exist, e.g., 20%, then the system 300 may replace the null values with fuel purchased values from the fuel card data for the same date range and vehicle(s).
  • the system 300 may initiate unit conversion 616.
  • unit conversion 616 the system 300 may convert units depending on the preferred output of the emission calculation 618. For example, a European customer may prefer to have emissions calculated using metric units, such as liters of fuel and kilometers of distance, while an American customer may prefer to have emissions calculated using imperial units, such as gallons of fuel and miles of distance. Units may be dictated by regulatory compliance requirements as well.
  • the system 300 may initiate emission calculation 618.
  • the system 300 may calculate scope 1 CO2 emissions (CO2e) by, for example, using the GHG protocol fuel-based method of calculation. An example of this method of calculation is described below.
  • the system 300 may calculate allocated fuel use (AFU) using one of the following formulas.
  • the AFU is the amount of fuel attributable to a particular customer of the vehicle 100 (or fleet of vehicles, etc.).
  • ⁇ ⁇ where M is the mass of a particular transported, and MT is the total mass of goods transported.
  • ⁇ ⁇ ⁇ where V is the volume of a particular and VT is the volume of goods transported.
  • the system 300 may calculate CO2e from unladen backhaul using the following formula.
  • Fuel BH is the quantity of fuel, of fuel type i, consumed from backhaul, which may, e.g., have the unit liters, and may be determined by multiplying the average fuel efficiency of the unladen vehicle 100 by the total distance traveled unladen; and EFuel is the emission factor for fuel type i, which may, e.g., have the unit kg CO2e/liter.
  • the system 300 may calculate scope 1 CO2e from transportation using a distance- based method, instead of, or in addition to, the fuel-based method.
  • the system 300 may use the distance-based method.
  • the distance-based method may use the following formula.
  • CO2e from transportation ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇
  • QGoods is the quantity of goods transported, which may, e.g., have the unit tonnes or m 3
  • D is the distance the goods were transported (e.g., km)
  • E Vehicle is the emission factor of vehicle type i, which may, e.g., have the unit (kg CO2e/tonne/km) or (kg CO2e/m 3 /km).
  • the system 300 may calculate scope 1 CH4 and N 2 O emissions by, for example, using a fuel-based method of calculation, or a distance-based method of calculation.
  • distance is multiplied by mass or volume of goods transported and relevant emission factors that incorporate average fuel consumption, average utilization, average size and mass or volume of the goods and the vehicles, and their associated GHG emissions.
  • D is the distance traveled by the vehicle (e.g., km);
  • ⁇ ⁇ is the emission factor for CH 4 (e.g., kg CH 4 /km);
  • ⁇ ⁇ is the emission factor for N2O (e.g., kg N2O/km).
  • the system 300 may also calculate scope 3 emissions.
  • Scope 3 emissions are defined by the GHG Protocol as all indirect emissions (not included in scope 2) that occur in the value chain of the reporting company, including both upstream and downstream emissions. While there are fifteen categories of scope 3 emissions, the following categories may be most relevant to the trucking sector. This means while customers may still report within all fifteen categories of scope 3 emissions, the system 300’s reports may prioritize data collection of the following categories.
  • Scope 3 Category 1 Purchased Goods and Services - Extraction, production, and transportation of goods and services purchased or acquired by the reporting company in the reporting year, not otherwise included in Categories 2 - 8.
  • the system 300 may employ a spend-based method for calculations for all categories of scope 3 emissions. This method estimates emissions for goods and services by collecting data on the economic value of goods and services purchased and multiplying it by relevant secondary (e.g., industry average) emission factors (e.g., average emissions per monetary value of goods).
  • the system 300 may also employ automatic data collection of any or all scope 3 categories, including categories 4, 8, 9, and 13 emissions, through supplier specific integrations.
  • Reports and data visualizations may show current emissions, historical emissions, predicted future emissions, and emissions generated over a customizable time window. Some calculations, reports, and data visualizations may rely on telematic data 302, FC data 304, or both telematic data 302 and FC data 304. For example, a cost of carbon calculation would require FC data, because fuel purchase data (including total amount spent on fuel) can only be collected by the Fuel Card system 200. [0074] Reports may include qualitative and quantitative sections related to emissions and/or overall climate impact.
  • Qualitative sections can be guided by topics, requirements, or policy that requires the user to share information on several impact areas including but not limited to: board-level oversight on climate related issues, the adoption of a scientific emission reduction target, regions operations were conducted, reporting boundaries, inherent climate-related risks with the potential to have a substantive financial impact to the company, etc. These sections such as risks and opportunities, targets and reduction, biodiversity, etc. serve to provide a deeper background on the company’s overall climate impact and their plans to reduce future emissions.
  • Quantitative sections of the reports contain data that is automatically calculated and generated from the system 300, mainly to report on current GHG emissions or emissions for a particular time period i.e., reporting year.
  • This section can include but is not limited to scope 1, scope 2, scope 3 emissions, emission amounts of each GHG, total energy usage (KWh/MWH), total emission footprint (aggregation of all three scopes), industry carbon rating based upon emissions performance compared to industry peers, average emissions per vehicle, idle-time emissions, total fuel consumed, impact of sustainable solutions integrated – ex. Month over month increase or decrease in emissions from the date of integrating an EV, emission reduction target, forecasted emissions, etc.
  • Data visualizations and/or reports may further include Sustainable Solution Markers (SSMs).
  • SSMs may mark a date that a particular change (e.g., an initiative or solution) was implemented by a customer (fleet manager, company, etc.), and allow recording of the details of the change.
  • the system 300 may generate emissions reduction recommendations based on telematic data, fuel card data, and/or emission calculations. The system 300 may do so by identifying which data elements have the greatest impact on a vehicle 100’s (or fleet’s, driver’s, etc.) emissions. The system may also compare telematic data, fuel card data, and/or emission calculations to industry standards or targets. For example, if a vehicle 100 has idle time data is that significantly above the industry standard, the system 300 may identify this problem, highlight it to the end user, and generate a recommendation to implement an idle time policy for drivers 208.
  • FIG.7 shows an example diagram of a logic flow 700 that may be executed by the system 300.
  • the logic flow 700 may occur within the data processing stage 410, and within the data acceptance stages 610, 612, and 614, within data flow 600.
  • the logic flow 700 may comprise three primary logic pathways, the telematic logic pathway 702, the FC logic pathway 704, and the combined logic pathway 706.
  • the telematic logic pathway 702 may be followed by the system 300 when the system 300 has access to telematic data 302 from the TCU 116 (e.g., via a fleet management software API), but does not have access to the FC data 304 from the FC system 200.
  • the system 300 may determine whether the distance data element contains more than a threshold number of null values, at stage 708. If the distance data element does contain more than a threshold number of null values and there are odometer values available, then the system may choose to proceed to stage 712, where the system 300 will substitute distance values with odometer values (for example, if the distance data element is not available, the system may default to using the max and min odometer readings).
  • the system 300 may proceed to stage 714, where the system 300 will remove the distance data element, and rely only on the fuel consumption data element for emission calculations. Also within the telematic logic pathway 702, the system 300 may determine whether the fuel consumption data element contains more than a threshold number of null values, at stage 710. If the fuel consumption data element does contain more than a threshold number of null values, then the system 300 may proceed to stage 716, where the system 300 will impute the missing (i.e., null) consumption values.
  • the FC logic pathway 704 may be followed by the system 300 when the system 300 has access to FC data 304 from the FC system 200, but does not have access to the telematic data 302 from the TCU 116.
  • the system 300 may determine whether the mileage data element contains more than a threshold number of null values, at stage 718. If the mileage data element does contain more than a threshold number of null values, then the system 300 may proceed to stage 720, where the system 300 will remove the mileage data element, and rely only on the fuel purchase data element for emission calculations. Also within the FC logic pathway 704, the system 300 may determine whether the fuel purchase data element contains more than a threshold number of null values, at stage 722.
  • the combined logic pathway 706 may be followed by the system 300 when the system 300 has access to both telematic data 302 and FC data 304, at least in part. Within the combined logic pathway 706, the system 300 may use the telematic data 302 as the primary data for emission calculations, as shown in stage 726. However, as a note, there may be some calculations that rely on FC data 304, such as cost of carbon.
  • the system may, in some instances where telematic data 302 and FC data 304 have overlapping data, create an average of values between the telematic data values and fuel card data values, and use the average values for emission calculations 618.
  • the system 300 may determine whether the distance data element contains more than a threshold number of null values, at stage 728. If the distance data element does contain more than a threshold number of null values and there are odometer values available, then the system may choose to proceed to stage 730, where the system 300 will substitute distance values with odometer values.
  • the system 300 may proceed to stage 731, where the system 300 will substitute distance values with mileage values (from the FCS 200). If the distance data element does contain more than a threshold number of null values and there are not sufficient odometer values or mileage values available to render the distance data element complete, the system 300 may proceed to stage 732, where the system 300 will remove the distance data element, and rely only on the fuel consumption data element for emission calculations. [0083] At stage 734, the system 300 may determine whether the fuel consumption data element contains more than a threshold number of null values.
  • FIG.8 shows an example data visualization chart 800 of scope 1 emissions over time of a fleet of vehicles 100.
  • FIG.9 shows an example emissions forecasting chart 900.
  • the emissions forecasting chart 900 may be generated based on the emissions forecasting calculations done as part of emission calculation 618.
  • the emissions forecasting chart 900 may comprise some quantity of actual data 902, such as the emissions data for a period of time (e.g., 1 year) up to the current date.
  • the emissions forecasting chart 900 may also comprise forecast data 904, which is the expected quantity of future emissions (calculated using the Bayesian method), in this case, plotted over time.
  • the emissions forecasting chart 900 may display a lower bound 906 and upper bound 908 of the expected quantity of future emissions (calculated using the Monte Carlo method).
  • the lower and upper bounds may be determined by being the emissions values above and below (respectively) which the future emissions falls in 95% of the future scenarios.
  • FIG.10 shows an example individual vehicle emissions chart 1000.
  • the individual vehicle emissions chart 1000 depicts the highest emitting vehicles within a fleet.
  • FIG.11 shows an example cost of carbon visualization 1100, which depicts the cost associated with each metric ton of CO2 emitted from a user’s vehicle(s). The cost is calculated by dividing the total amount of CO 2 emissions for a given timeframe by the total spend on fuel purchases in that timeframe (derived from fuel card data).
  • the emissions cloud platform can identify areas of cost- savings, emission reduction, and more.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé de surveillance d'émissions de véhicules qui consiste à recevoir des données télématiques de véhicule et des données d'achat de carburant pour les véhicules. Le procédé consiste à formater les données télématiques et les données d'achat de combustible selon un schéma de structure de données et à stocker les données télématiques et les données d'achat de carburant dans une structure de données. Le procédé consiste à déterminer si les données télématiques ou les données d'achat de carburant contiennent des informations suffisantes pour déterminer une quantité d'émissions générées par le ou les véhicules sur une période de temps et en réponse à la détermination du fait que l'une des données télématiques de véhicule ou des données d'achat de carburant ne contient pas suffisamment d'informations pour déterminer les émissions générées par le ou les véhicules sur une période de temps particulière, à utiliser au moins une partie de l'autre des données télématiques de véhicule ou des données d'achat de carburant pour déterminer les émissions générées par le ou les véhicules sur une période de temps particulière.
PCT/US2024/032408 2023-06-12 2024-06-04 Calcul et rapport de données d'émissions Pending WO2024258680A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202363472475P 2023-06-12 2023-06-12
US63/472,475 2023-06-12
US18/394,451 US12469338B2 (en) 2023-06-12 2023-12-22 Emissions data calculation and reporting
US18/394,451 2023-12-22

Publications (1)

Publication Number Publication Date
WO2024258680A1 true WO2024258680A1 (fr) 2024-12-19

Family

ID=91664107

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/032408 Pending WO2024258680A1 (fr) 2023-06-12 2024-06-04 Calcul et rapport de données d'émissions

Country Status (1)

Country Link
WO (1) WO2024258680A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090069999A1 (en) * 2007-09-11 2009-03-12 Gm Global Technology Operations, Inc. Onboard trip computer for emissions subject to reduction credits
US20120209579A1 (en) * 2010-12-31 2012-08-16 Fansler Thomas S Statistical Modeling and Analysis of Fuel-Related Factors in Transportation Industries

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090069999A1 (en) * 2007-09-11 2009-03-12 Gm Global Technology Operations, Inc. Onboard trip computer for emissions subject to reduction credits
US20120209579A1 (en) * 2010-12-31 2012-08-16 Fansler Thomas S Statistical Modeling and Analysis of Fuel-Related Factors in Transportation Industries

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
CASSIASKUN: "Vehicle telematics: A literature review", 2007, UNIV. NEW HAMPSHIRE, pages: 54
CHENCHIEN, JOURNAL OF COMPUTER AND COMMUNICATIONS,, vol. 3, 2015, pages 153 - 158
HO ET AL., INTERNATIONAL JOURNAL OF AUTOMOTIVE TECHNOLOGY, vol. 7, no. 4, 2006, pages 509 - 517
MCDONNELL ET AL., SENSORS, vol. 21, no. 10, 2021, pages 3517
TELETRAC: "How to measure fuel consumption - Teletrac Navman US", 22 March 2023 (2023-03-22), pages 1 - 4, XP093201500, Retrieved from the Internet <URL:https://web.archive.org/web/20230322053504/https://www.teletracnavman.com/fleet-management-software/resources/how-to-measure-fuel-consumption> [retrieved on 20240804] *

Similar Documents

Publication Publication Date Title
US9563893B2 (en) Method and system for detection of a fuel card usage exception
US8214075B2 (en) System and method for modelling a flight
US20190172010A1 (en) Freight shipment booking system
US9940615B2 (en) Automated pairing of payment products and mobile to mobile devices
US10755284B2 (en) Method and apparatus for preparing, storing and recording compliant records for motor carriers, registrants, and governmental organizations
US20140222698A1 (en) Systems and Methods for Tracking Renewable Energy Credits
US20180158145A1 (en) Resource planning system, particularly for vehicle fleet management
US20240127264A1 (en) Systems, methods, and devices for automated emissions data collection and analysis
Iacob et al. Towards a reference architecture for fuel-based carbon management systems in the logistics industry
CN111241161A (zh) 发票信息挖掘方法、装置、计算机设备及存储介质
WO2016003794A1 (fr) Tableau de bord d&#39;opportunités
RU2745340C2 (ru) Виртуальный рынок для распределяемых инструментальных средств в среде предприятия
US12469338B2 (en) Emissions data calculation and reporting
WO2024258680A1 (fr) Calcul et rapport de données d&#39;émissions
CN114202313A (zh) 车辆油耗管理方法、装置、计算机存储介质和电子设备
US20240420512A1 (en) Interfaces and systems for improving and facilitating fleet management
KR101392879B1 (ko) 이동 배출원의 탄소배출량 산정 자동화 방법 및 시스템
US20070038532A1 (en) Method and system for integrated service delivery
CN119810939B (zh) 一种针对etc服务异常的全周期智能预警方法及系统
CN113240439A (zh) 目标车辆识别方法、装置、电子设备及存储介质
US20250285152A1 (en) Interfaces and systems for real time and near real time fleet resource management
US12197616B1 (en) Online software platform (OSP) querying client data about relationship instances for application of permission digital rules in addition to resource digital rules for the relationship instances
US20250224242A1 (en) Navigation guidance for vehicles to reduce carbon emission exposure
Du Preez The integration of informal minibus-taxi transport services into formal public transport planning and operations-A data driven approach
Thangpromphan et al. E-Business Platform for Enterprise Green Logistics Management: A Case Study of Logistics Business in Bangkok, Suburban Areas, and Laem Chabang

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24735833

Country of ref document: EP

Kind code of ref document: A1