An apparatus and a method to correct missing charge detail data

Abstract

Example embodiments enable estimating and correcting missing charge data. An apparatus (100) is configured to determine that a charging transaction has probably stopped at a charging station (200) based on one or more indirect signals. The apparatus may be further configured to estimate one or more values related to the charging transaction before the correct values are received, and in case the correct values are never received, the estimated values may be used in subsequent processes. The value estimations may be performed automatically, without requiring manual work from an operator.

Description

[0001] AN APPARATUS AND A METHOD TO CORRECT MISSING CHARGE DETAIL DATA

[0002] TECHNICAL FIELD

[0003] The present application generally relates to electric vehicle charging stations . Some example embodiments of the present application relate to correction of missing data from electric vehicle charging stations , for example , in charge detail records .

[0004] BACKGROUND

[0005] When electric vehicle charging stations charge electric vehicles , the electric vehicle charging stations may be configured to send data of the charging to a management system . EP 3693205 Al discloses an apparatus for managing missing charge data . OPEN CHARGE ALLIANCE OCPP 2 . 0 . 1 Part 2 - Specification, Edition 2 FINAL, 22 - 12 - 15 discloses an OCPP standard document of communication protocol relating to charging of electric vehicles . WO 2022157418 Al discloses a method for determining if electric vehicle charging station is online or offline . However, some data may not be received by the management system, for example , when a fault occurs at the charging station .

[0006] SUMMARY

[0007] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description . This summary is not intended to identify key features or essential features of the claimed subj ect matter, nor is it intended to be used to limit the scope of the claimed subj ect matter . Example embodiments may enable determining that a charging transaction has probably stopped at a charging station based on one or more indirect signals . Example embodiments may further enable estimating one or more values related to the charging transaction before the correct values are received, and in case the correct values are never received, the estimated values may be used in subsequent processes . The value estimations may be performed automatically, without requiring manual work from an operator .

[0008] According to a first aspect , an apparatus for managing missing charge data is provided . The apparatus comprises at least one proces sor ; and at least one memory comprising instructions which, when executed by the at least one proces sor, cause the apparatus at least to receive a start-message from an electric vehicle charging station indicating a charging transaction has started; after the start-message is received, detect an indication that the charging transaction has stopped, without a stop-message indicating the charging transaction has stopped being received from the electric vehicle charging station, wherein the indication is detected based on one or more messages at least one of received or missing from the electric vehicle charging station ; determine an estimate value for at least one parameter of the charging transaction based on the one or more received messages ; calculate a probability that the charging transaction is stopped based on the estimated value and a mean value of the parameter for the electric vehicle charging station ; update missing data in a charge detail record of the charging transaction with the at least one estimated value and the probability; and determine , based on the probability, whether to proceed to processing the charge detail record or to perform at least one action to obtain data for updating the at least one estimated value . In an embodiment , the at least one memory further comprises instructions which, when executed by the at least one processor, cause the apparatus to update a data status of the charge detail record to indicate the charge detail record comprises at least one estimated value ; update a record status of the charge detail record to indicate the charging transaction is suspected to have stopped; if the stop-message is received, replace the at least one estimated value with a value determined based on the stop-message and update the data status to indicate the charge detail record comprises confirmed values and the record status of the charge detail record to indicate the charging transaction has stopped; and perform processing of the charge detail record based on the data status and the record status .

[0009] In an embodiment , in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one memory, cause the apparatus to monitor meter value messages received from the electric vehicle charging station ; detect the indication that the charging transaction has stopped based on a plurality of consecutive meter value messages having a same energy reading; determine an estimated energy usage based on a latest received meter value message .

[0010] In an embodiment , in addition or alternatively, the at least one memory further comprises instructions which, when executed by the at least one processor, cause the apparatus to determine an estimated end of energy delivery time based on a last meter value message having a different energy reading than a preceding meter value message .

[0011] In an embodiment , in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the apparatus to : monitor status notifications received from the electric vehicle charging station ; detect the indication that the charging transaction has stopped based on a status notification indicating an unplugged electric vehicle and wherein the stop-message is not received within a predetermined interval from the status notification ; and determine an estimated idle time of the charging transaction based on a time of a last received meter value message having a different energy reading than a preceding meter value message from the electric vehicle charging station and a timestamp of the status notification ; determine the probability based on the estimated idle time and a mean value of an idle time at the electric vehicle charging station .

[0012] In an embodiment , in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the apparatus to : put the charge detail record to quarantine when the probability is above a predetermined threshold; and rej ect or approve the charge detail record in quarantine for further proces sing based on one or more criteria ; and remove the rej ected or approved charge detail record from the quarantine .

[0013] In an embodiment , in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one proces sor, cause the apparatus to after detecting the plurality of consecutive meter value messages having the same energy reading, send a first trigger message to the electric vehicle charging station requesting a latest stop message ; if the stop-message for the charging transaction is received in response to the first trigger message , update at least one of the at least one estimated value with a value determined based on the stop-message, a data status of the charge detail record to indicate the charge detail record comprises confirmed values or a record status of the charge detail record to indicate the charging transaction has stopped; if the stop-message is not received in response to the first trigger message , send a second trigger message to the electric vehicle charging station requesting a latest status notification ; if a status notification is not received from the electric vehicle charging station in response to the second trigger message , calculate the probability; if the probability is below the predetermined threshold, resend the second trigger message after a second predetermined interval ; and if the probability is above until the predetermined threshold, put the charge detail record to quarantine .

[0014] In an embodiment , in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the apparatus to receive a second start-message from the electric vehicle charging station indicating a new charging transaction has started; detect that the stopmessage for the previous charging transaction is not received within a third predetermined interval after the second start-message ; send a first trigger message for the electric vehicle charging station requesting for a latest stop-message ; if the stop-message is received in response to the f irst trigger message , update at least one of the at least one estimated value with a value determined based on the stop-message , the data status of the charge detail record to indicate the charge detail record comprises confirmed values or the record status of the charge detail record to indicate the charging transaction has stopped; if the stop message is not received in response to the first trigger message , calculate the probability; if the probability is above the predetermined threshold, put the charge detail record to quarantine .

[0015] In an embodiment , in addition or alternatively, the indication is detected when at least one of one or more messages expected from the electric vehicle charging station are not received within a fourth predetermined interval or when the electric vehicle charging station is offline for the fourth predetermined interval ; and wherein the at least one memory comprises instructions which, when executed by the at least one processor, cause the apparatus to update the charge detail record with at least one of an estimated plugged- in end time based on a timestamp of a last message received from the electric vehicle charging station, an estimated energy value based on an energy reading of a last received meter value message , or an estimated energy delivery end time based on a timestamp of a last meter value message that had a different energy reading than a preceding meter value message ; determine an estimate of a current charging time based on a starttime from the start-message and a current time ; calculate the probability based on the current charging time and a mean value for a charging time at the electric vehicle charging station ; if the probability is less than the predetermined threshold, wait the fourth predetermined interval if the electric vehicle charging station sends the expected message or becomes online , and if the electric vehicle charging station is still faulted, update the charge detail record with the at least one estimated value and recalculate the probability; if the probability is above the predetermined threshold, put the charge detail record to quarantine .

[0016] In an embodiment , in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the apparatus to detect that a stop-message associated a charge detail record in quarantine , approved or rej ected is received; check configuration for late received stopmessages ; based on the configuration, either update at least one of the at least one estimated value based on the stop-message , a data status of the charge detail record values to confirmed or a record status of the charge detail record to indicate the charging transaction has stopped, or ignore the stop-message ; and if the charge detail record is updated, approve the charge detail record for further processing .

[0017] In an embodiment , in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the apparatus to output a li st of charge detai l records in quarantine to a user with the at least one estimated value and the probability; receive a user input indicating one or more charge detail records in the quarantine to be approved or rej ected .

[0018] In an embodiment , in addition or alternatively, the one or more criteria comprise at least one of a limit for energy usage , a duration of charging transaction, a limit for the probability, a quarantine time , an identity of the electric vehicle charging station, a model of the electric vehicle charging station, a vendor of the electric vehicle charging station, a start time of the charging transaction, an end time of the charging transaction, cost of the charging transaction, an owner of the electric vehicle charging station, or a criterion set by a user .

[0019] In an embodiment , in addition or alternatively, the at least one memory comprises instructions which, when executed by the at least one processor, cause the apparatus to receive the stop-message from the electric vehicle charging station after the charge detail record put to quarantine is approved or rej ected; and update the at least one estimated value of the rej ected charge detail record based on the stop-message and approve the charge detail record for further processing .

[0020] According to a second aspect , a computer- implemented method is provided . The method comprises receiving a start-message from an electric vehicle charging station indicating a charging transaction has started; after the start-message is received, detecting an indication that the charging transaction has stopped without a stop-message indicating the charging transaction has stopped being received from the electric vehicle charging station, wherein the indication is detected based on one or more mes sages at least one of received or missing from the electric vehicle charging station ; determining an estimate value for at least one parameter of the charging transaction based on the one or more messages ; calculating a probability that the charging transaction is stopped based on the estimated value and a mean value of the parameter for the electric vehicle charging station ; updating missing data in a charge detail record of the charging transaction with the at least one estimated value and the probability; and determining, based on the probability, whether to proceed to processing the charge detail record or to perform at least one action to obtain data for updating the at least one estimated value .

[0021] According to a third aspect , a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of the second aspect .

[0022] According to a fourth aspect , there is provided a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of the second aspect .

[0023] Many of the attendant features wil l be more readily appreciated as they become better understood by reference to the following detailed description considered in connection with the accompanying drawings .

[0024] BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The accompanying drawings , which are included to provide a further understanding of the example embodiments and constitute a part of this specification, illustrate example embodiments and together with the description help to explain the principles of the example embodiments . In the drawings :

[0026] FIG . 1 illustrates an example of an apparatus configured to practice one or more example embodiments ;

[0027] FIG . 2 illustrates an example of an electric vehicle charging station sending a stop-message and an electric vehicle charging station not sending a stopmessage according to an example embodiment ;

[0028] FIG . 3 illustrates an example of a data model of an apparatus configured to manage charge data according to an example embodiment ;

[0029] FIG . 4 illustrates an example of a flow chart of a method to correct missing data after a received status notification according to an example embodiment ;

[0030] FIG . 5 illustrates an example of a flow chart of a method to correct missing data when energy delivery in an electric vehicle charging station has stopped according to an example embodiment according to an example embodiment ;

[0031] FIG . 6 illustrates an example of a flow chart of a method to correct missing data when a start-message of a new charging transaction is sent before sending a stop-message of a previous charging transaction according to an example embodiment ;

[0032] FIG . 7 illustrates an example of a flow chart of a method for correcting missing data when a charging station is not communicating according to an example embodiment ;

[0033] FIG . 8 illustrates an example of a flow chart of a method for approving a charge detail record in quarantine according to an example embodiment ;

[0034] FIG . 9 illustrates an example of a user interface for managing charging detail records according to an example embodiment ;

[0035] FIG . 10 illustrates an example of a user interface for managing quarantine rules according to an example embodiment ; FIG . 11 illustrates an example of a flow chart of an automatic approval or rej ection process for quarantined charge detail records according to an example embodiment ;

[0036] FIG . 12 illustrates an example of a user interface for late stop-message configuration according to an example embodiment ; and

[0037] FIG . 13 illustrates an example of a method for correction of missing charge detail data according to an example embodiment .

[0038] Like references may be used to designate like parts in the accompanying drawings .

[0039] DETAILED DESCRIPTION

[0040] Reference will now be made in detail to example embodiments , examples of which are illustrated in the accompanying drawings . The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present examples may be constructed or utili zed . The description sets forth the functions of the example and a possible sequence of operations for constructing and operating the example . However, the same or equivalent functions and sequences may be accomplished by different examples .

[0041] Electric vehicle charging stations (CS ) are used to charge electric vehicles (EV) . In this disclosure , the electric vehicle charging stations can be called charging stations . The charging stations may be connected to an apparatus acting as a charging station management system (CSMS ) . The apparatus may communicate with the charging station with an open protocol , such as an OCPP protocol (Open Charge Point Protocol ) . EV drivers may own electric vehicles and charge their EVs on charging stations . The charging stations may inform the apparatus when a new charging transaction has been started and when it has been stopped by sending a message to the apparatus . These messages may be referred to as startmessages and stop-messages . When there is an ongoing charging transaction between a charging station and an EV, the charging station may send a start-mes sage with a start time of the charging . During charging, the charging station may send messages comprising status notifications and meter values . When the charging transaction ends , the charging station may send a stopmessage where it informs the apparatus what was the final duration (e . g . , minutes ) and used energy (e . g . , watt hours ) of the charging transaction . The apparatus may create a record based on the information of the stop-message . The record may be referred to as charge detail record (CDR) . The CDR may contain charging related data, for example start time , end time , used energy, which EV driver did the charge , on which charging station the transaction took place and the like . This information may be used for further processes , such as for invoicing the EV driver for charging .

[0042] A charging station may have a fault and do not send the stop-message to the apparatus when a charging transaction ends . When an EV driver stops charging and disconnects the EV from the charging station, the charging station becomes available for new charges . However, i f the charging station does not send a stopmessage to the apparatus , from the apparatus perspective there is still an ongoing charge . In other words , the apparatus has not received information from the charging station that charging has stopped, so the apparatus may still presume that there is an ongoing charging transaction . I f the apparatus does not receive a stopmessage , it may not create correct CDR data which may cause issues . The apparatus may think that a charging transaction has been going on for days or even for weeks and may generate a too large invoice for the EV driver or the apparatus may not be able to invoice the EV driver at all .

[0043] An obj ective is to provide automatically as closely correct information as possible when a charging station does not report expected data , such as a stopmessage for a charging transaction . An apparatus may be configured to create a CDR record with estimated values before a stop-message is received, and update the estimated values with values from the stop-message if the stop-message is later received . I f the stop-message is never received, the CRD record with the estimated values may be used for subsequent tas ks at the apparatus or an external system .

[0044] An example embodiment provides a method to correct missing data . The missing data may be associated with a charging transaction at a charging station . The method may enable an apparatus monitoring the charging transaction to estimate when the charging transaction has stopped even when the charging station fails to send a stop-message . The method may further enable the apparatus to estimate one or more attributes , which the charging station failed to send to the apparatus . The attributes may be estimated indirectly based on other attributes received from the charging station . The method may further enable estimating when the charging transaction stopped based on a calculated probability . The probability may be further used for decision making, such as approving or rej ecting the CDR record for later use , such as invoicing, statistics , etc . Hence , for example a CDR record may be estimated, created and finali zed even when there is some data missing from a charging station based on other available data and calculated probabilities . FIG . 1 illustrates an example of an apparatus 100 configured to practice one or more example embodiments .

[0045] The apparatus 100 may comprise at least one processor 102 . The at least one processor 102 may comprise , for example , one or more of various processing devices , such as for example a co-processor, a microprocessor, a controller, a digital signal processor ( DSP) , a processing circuitry with or without an accompanying DSP, or various other processing devices including integrated circuits such as , for example , an application specific integrated circuit (AS IC) , a field programmable gate array ( FPGA) , a microcontroller unit (MCU) , a hardware accelerator, a special-purpose computer chip, or the like .

[0046] The apparatus 100 may further comprise at least one memory 104 . The memory may be configured to store , for example, computer program code 106 or the like , for example operating system software and application software . The memory 104 may comprise one or more volatile memory devices , one or more non-volatile memory devices , and / or a combination thereof . For example , the memory may be embodied as magnetic storage devices ( such as hard disk drives , magnetic tapes , etc . ) , optical magnetic storage devices , or semiconductor memories ( such as mask ROM, PROM (programmable ROM) , EPROM (erasable PROM) , flash ROM, RAM ( random access memory) , etc . ) .

[0047] The apparatus 100 may further comprise communication interface 108 configured to enable apparatus 100 to transmit and / or receive information, to / from other apparatuses , such as the charging stations . The communication interface may be configured to provide at least one wireless radio connection, such as for example a 3GPP mobile broadband connection (e . g . 3G, 4G, 5G) . However, the communication interface may be configured to provide one or more other types of connections , for example a wireless local area network (WLAN) connection such as for example standardi zed by IEEE 802 . 11 series or Wi-Fi alliance ; a short range wireless network connection such as for example a Bluetooth, NFC (near-field communication) , or RFID connection ; a wired connection such as for example a local area network (LAN) connection, a universal serial bus (USB) connection or an optical network connection, or the like ; or a wired Internet connection . Communication interface 108 may comprise , or be configured to be coupled to, at least one antenna to transmit and / or receive radio frequency signals . One or more of the various types of connections may be also implemented as separate communication interfaces , which may be coupled or configured to be coupled to a plurality of antennas . The apparatus 100 may further comprise a user interface 110 comprising an input device and / or an output device .

[0048] When the apparatus 100 is configured to implement some functionality, some component and / or components of the apparatus 100 , such as for example the at least one processor 102 and / or the memory 104 , may be configured to implement this functionality . Furthermore , when the at least one processor 102 is configured to implement some functionality, this functionality may be implemented using program code 106 comprised, for example , in the memory 104 .

[0049] The functionality described herein may be performed, at least in part , by one or more computer program product components such as software components . According to an embodiment , the apparatus comprises a processor or processor circuitry, such as for example a microcontroller, configured by the program code when executed to execute the embodiments of the operations and functionality described . Alternatively, or in addition, the functionality described herein can be performed, at least in part , by one or more hardware logic components . For example , and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs ) , application-specific Integrated Circuits (AS ICs ) , application-specific Standard Products (ASSPs ) , System- on-a-chip systems ( SOCs ) , Complex Programmable Logic Devices (CPLDs ) , Graphics Processing Units (GPUs ) .

[0050] The apparatus 100 comprises means for performing at least one method described herein . In one example , the means comprises the at least one processor 102 , the at least one memory 104 including program code 106 configured to , when executed by the at least one processor 102 , cause the apparatus 100 to perform the method .

[0051] In an embodiment , the apparatus 100 may be configured to store an algorithm for monitoring usage of a charging station . The apparatus 100 may be configured to keep track of charging session data ( i . e . , charging transaction data) during charging at the charging station, and estimate real usage of the charging station in case there is no stop-message received by the apparatus 100 . The usage may refer to energy-based usage data, or time-based usage data, or both . The apparatus 100 may be configured to update a CRD record with the estimated data .

[0052] The apparatus 100 may be further configured to store an algorithm for stop detection . The apparatus 100 may be configured to monitor different indirect information from the charging station to detect if charging has been stopped at the charging station even though the charging station has not sent the stopmessage to the apparatus 100 . The apparatus 100 may be configured to update a CDR with an estimated stop time .

[0053] The apparatus 100 may be configured to perform a quarantine process for records updated with estimated information . The apparatus 100 may be configured to put a CDR record to quarantine when the apparatus determines that charging may have been stopped at the charging station even if the charging station has not sent a stop-message .

[0054] The apparatus 100 may be configured to perform a CDR finalization process. The apparatus 100 may be configured to take a CDR record from the quarantine and update the CDR record to a final record, for example, if the apparatus 100 concludes that the charging station may never send the stop-message.

[0055] The apparatus 100 may comprise for example a computing device such as for example a server device, a client device, a mobile phone, a tablet computer, a laptop, or the like. Although the apparatus 100 is illustrated as a single device it is appreciated that, wherever applicable, functions of the apparatus 100 may be distributed to a plurality of devices. In one example, the apparatus 100 may comprise a CSMS server device. The apparatus 100 may be configured to operate in a cloud. The apparatus 100 may be configured to communicate with charging stations of different models and vendors, for example, by using an OCPP protocol, or the like.

[0056] FIG. 2 illustrates an example of an electric vehicle charging station sending a stop-message and an electric vehicle charging station not sending a stopmessage according to an example embodiment.

[0057] A charging station 200 may send a plurality of messages to an apparatus 100 to inform the apparatus 100 about progress and attributes related to a charging transaction. When the charging station 200 is working correctly, the charging station 200 may first send a start-message. The start-message may comprise an identifier for the charging transaction and date and time when the charging started (e.g., start: id=12, start=2023-04-27 15:20) . Thereafter, during the charging, the charging station 200 may send status messages (e.g., status notifications) and meter values (i.e., how much energy has been charged so far) . When the charging ends, the charging station may send a stopmessage. The stop-message may comprise the identifier for the charging transaction, a final value for charged energy and a date and a time when the charging transaction stopped (e.g., Stop: Id=12, energy=1520, stop=2023-04-27 17:32) . These messages received from the working charging station are illustrated as messages A in FIG. 2. After receiving the stop-message, the apparatus 100 may be configured to update a record of the charging transaction 202, i.e., a charge detail record, CDR. The CDR may comprise, for example, the identifier, the final value for charged energy, the start time and the stop time of the charging transaction obtained from the messages A.

[0058] When the charging station 200 has a fault, the charging station may send messages B. For example, the charging station 200 may first send a start-message (e.g., Start: Id=13, start=2023-04-28 19:25) . During charging, the charging station 200 may again send status messages and meter values related to the charging transaction. However, because of the fault, the charging station 200 may not send a stop-message. Hence, the apparatus 100 may not be able to update the CDR data with final values from the charging station 200. For example, the CRD 202 may only comprise the identity for the charging transaction and the start time received in the start-message.

[0059] One approach to update the CDR with missing data is by manual work. For example, a service desk agent may receive a support request from an EV driver about an ongoing charge that has not been stopped in a mobile application, and can then update the data manually to the CDR. Alternatively, the CDRs with missing data can be ignored, and give charging for free for EV drivers if the charging station does not report correct stop-message. However, manually checking the data creates high cost . Often the cost of correcting a CDR is higher than the profit from the charging transaction . For example , if a typical cost for charging would be 5 €, it would not be meaningful for somebody to spend an hour for checking and fixing the 5 € cost . Also , if the invalid CDRs were ignored, even if the cost of a single charging transaction is low, the total sum can be high when there are thousands of invalid CDRs .

[0060] When no stop-message is received by the apparatus 100 from the charging station 200 , the apparatus 100 may be configured to use other available data to at least one of estimate , create or f inali ze a CDR record .

[0061] After the charging has started, the apparatus 100 may be configured to continuously monitor energy usage , time usage (during the charging transaction) , and a status of the charging station 200 . Based on the monitored data , the apparatus 100 may be conf igured to detect abnormal behaviour that may indicate that charging at the charging station 200 has stopped in reality, even if no stop-message is received .

[0062] I f the apparatus 100 detects , after analysis of the monitored data, that the charging may have stopped, the apparatus 100 may be configured to gather data from the charging station with other means ( i . e . , other than the stop-message ) to see if charging has indeed stopped . I f the apparatus 100 is able to find out that charging has been stopped although no stop-message is received, the apparatus 100 may be configured to update the CDR with a latest monitored energy- and / or time-usage . The apparatus 100 may be further configured to put the CDR record to quarantine .

[0063] I f the apparatus 100 does not receive the stopmessage from the charging station 200 within a certain time , the apparatus 100 may be configured to take the CDR record from the quarantine and update the CDR record with estimated data . The CDR record, now comprising all needed data for invoicing, can be then used for invoicing an EV driver .

[0064] FIG . 3 il lustrates an example of a data model of an apparatus configured to manage charge data according to an example embodiment .

[0065] The apparatus 100 may be configured to store information about EV drivers 302 . The apparatus 100 may be configured to store information about one or more charging stations 200 . When an EV driver 302 charges their EV on a charging station 200 , the apparatus 100 may create a CDR of the charging transaction . CDR is an example of charge data .

[0066] Each CDR may have one or more attributes . A CDR may comprise at least one of an identity ( ID) of a charging transaction, and ID of a charging station, a start time of the charging transaction, an end ( stop) time of the charging transaction, charged energy, a data status or a record status . The data status may be set by the apparatus to indicate if data comprised in the CDR record comprises estimated values ( an estimate state ) or confirmed values ( a confirmed state ) . The data status may be set to the confirmed state when a stopmessage for the charging transaction is received from the charging station 200 . The data status may be set to the estimate state when the apparatus suspects that the charging transaction is stopped when if no stop-message is received . The apparatus 100 may be configured to keep the estimate status until it receives the stop-message . I f the stop-message is later received, the apparatus 100 may update the data status to confirmed . I f the stopmessage is never received, the CDR in the estimate state still shows the estimated data determined by the apparatus by indirect evaluation . The record status may indicate a current progress of the charging transaction at the charging station 200 . The record status may be set by the apparatus 100 to have one of the following states : started, in progress , suspected stop or stopped . The record status may be set to started when a start message is received by the apparatus 100 from the charging station 200 . The record status may be set to in progress when one or more status notifications or meter values are received by the apparatus 100 from the charging station 200 . The record status may be set to suspected stop, when the apparatus 100 suspects that the charging transaction has stopped, even if no stopmessage is received from the charging station 200 . The record status may be set to stopped when the stopmessage is received from the charging station 200 .

[0067] The apparatus 100 may be configured to determine when the charging station has a fault based on one or more missing or received messages from the charging station . For example , the apparatus 100 may be configured to detect a fault when the charging station sends a status notification that tells that the charging station is no longer charging, but no stop-message confirming the stop of charging is received from the charging station . In addition, the apparatus 100 may be configured to detect a fault when the charging station has sent a plurality of meter values with the same energy reading . For example , if the charging station has already sent 10 meter values with the same reading, thi s may mean that the charging station is no longer delivering energy to the EV . The apparatus 100 may also be configured to detect a fault based on a new startmessage received from the charging station for a new charging transaction, without sending a stop-message for the previous charging transaction . The apparatus 100 may also monitor when the charging station stops sending any messages to the apparatus 100 , for example , when the charging station goes offline . When the apparatus detects a fault , the apparatus 100 may determine the charging transaction may have stopped . The apparatus 100 may be further configured to update the record status to the suspected stop state . The suspected stop state may be associated with a probability for the stop of charging calculated by the apparatus 100 .

[0068] The apparatus 100 may be configured to put the CDR record 202 to quarantine if the apparatus 100 suspects that there is something wrong with the data . The CDR record may be quarantined, for example , when the data status is set to the estimate state or when the suspected stop is set as the record status for the CDR . The quarantine storage may comprise , for example , an ID of CDR, a quarantine status and a probability of a stopped charging transaction of the quarantined CDR . The apparatus 100 may set the quarantine status to open, approved or rej ected . The quarantine status may be set to open, when the quarantined CDR record has not yet been processed . The quarantine status may be set to approved when the CDR record is approved to be processed, for example , for invoicing, and set to rej ected when it is not approved for further processing . The stop probability may be calculated by the apparatus 100 . The probability indicating how certain the apparatus 100 is that the charging has been stopped at the charging station 200 even if the charging station 200 has not sent the stop-message for the charging transaction may be also referred to as a stop probability .

[0069] The apparatus 100 may be configured to monitor one or more parameters of a charging transaction in the CDR data . For example , the apparatus 100 may be configured to monitor energy usage during the charging transaction . The energy usage may indicate how many kilowatts per hour did an EV charge in total during the charging transaction . The apparatus 100 may be configured to monitor plugged-in time during the charging transaction . The plugged-in time may indicate a time starting from the point when the EV was plugged- in to the charging station, and ending to the time when the EV was unplugged from the charging station . The apparatus 100 may be configured to monitor energy delivery time . Energy delivery time may be also referred to as charging time . The energy delivery time may indicate a time starting from the point when the energy is first delivered from the charging station to the EV, and ending to the point when the energy delivery stops . The apparatus 100 may be further configured to monitor an idle time . The idle time may indicate a time starting when the energy delivery from the charging station to the EV ends , and ending when the EV is unplugged .

[0070] For example , the final energy usage may be obtained by the apparatus 100 from a stop-message received from the charging station . The plugged-in time may be calculated by the apparatus 100 from status notifications received from the charging station . The energy delivery time and idle time can be calculated by the apparatus 100 from meter values received from the charging station . However, when the charging station fails to send one or more of the information needed for determining the parameters , the apparatus 100 may be configured to estimate the parameters based on other information received from the charging station .

[0071] For example, when no stop-message is received, the apparatus 100 may be configured to determine the final energy usage based on a latest meter value received from the charging station . Further, when no status notification indicating that the EV is unplugged is received, the apparatus 100 may be configured to determine the plugged-in time based on last two meter values received from the charging station having a difference in energy readings . In other words , when two consecutive meter values have the same energy reading, the apparatus 100 may determine that the EV is unplugged . The apparatus 100 may be configured to assume that the last time energy was delivered to the EV was the time when the EV was unplugged ( i . e . , the energy readings in consecutive meter values were the same ) . The apparatus 100 may be further configured to determine a start of the idle time from a last meter value that was different from a preceding meter value received from the charging station . The apparatus 100 may be configured to determine an end of the idle time based on the end of the plugged-in time .

[0072] FIG . 4 il lustrates an example of a flow chart of a method to correct missing data after a received status notification according to an example embodiment . The method may be performed by a computing device, such as the apparatus 100 . There may be an ongoing charging transaction at a charging station, and the charging transaction may have sent a start-message and one or more meter values to the apparatus 100 . The apparatus 100 may have set a CDR record to a in progress state based on the messages .

[0073] At 400 , the apparatus 100 receives a new status notification from the charging station .

[0074] At 402 , the apparatus checks if the charging station is still charging according to the status notification . I f yes , the apparatus 100 determines that no actions may be needed at 404 . When the status notification indicates that a charging cable has been unplugged and an EV is no longer connected to the charging station, and the apparatus 100 has not received a stop-message from the charging station, the apparatus 100 may proceed to operation 406 .

[0075] At 406 , the apparatus 100 may be configured to wait a predetermined interval to see if the charging station sends the stop-message . The predetermined interval may be , for example , 5 minutes . However, the predetermined interval may have any configured value , such as 2 minutes , 10 minutes , 30 minutes , or the like .

[0076] At 408 , the apparatus 100 may determine if the charging station sent the stop-message within the predetermined interval . At 410 , if the stop-message is received by the apparatus 100 within the predetermined interval , the apparatus 100 may be configured to update the CDR record with confirmed status for CDR data and with a stopped status for the CDR record .

[0077] At 412 , if the stop-message is not received by the apparatus 100 within the predetermined interval , the apparatus 100 may be configured to update the CDR record with at least one estimated value (e . g . , duration, energy usage , etc . ) and set the CDR data to an estimate state . The apparatus 100 may be further configured to calculate a probability that the charging has been stopped . The probability may be stored in the CDR record . For example , the apparatus 100 may determine that after the status notification is received without receiving the stop-message , the probability that the charging has stopped is 95% . The probability may not be 100 % , since it may be also possible that the charging station has sent an invalid status notification, or that the stop-message will j ust arrive at some point later .

[0078] For example , a charging station may have sent the same energy readings for the last 15 minutes , but not a stop-message . Therefore , it can be estimated that energy is not being delivered to an EV anymore . The charging station may have a fault , but this can be also normal behaviour : it is fairly common that EV drivers do not disconnect the EV from the charging station immediately after the EV' s battery is full . The charging station may only send a stop-message after the EV has been disconnected . So , it may be suspected that with a 10 % probability charging has been stopped, but not with 100 % certainty . However, if the charging station has been sending the same energy readings for the last 30 days , it may indicate with 99% probability that there is a fault and that in reality charging has been stopped, even if there hasn' t been a stop-message . At 414 , the apparatus 100 may be configured to update the record status of the CDR to suspected stop .

[0079] At 416 , the apparatus 100 may be configured to add the CDR record with the suspected stop state to quarantine . Hence , the quarantined CDR may not be used for further processes until the apparatus 100 has determined if the CDR is approved or rej ected .

[0080] FIG . 5 il lustrates an example of a flow chart of a method to correct missing data when energy delivery in an electric vehicle charging station has stopped according to an example embodiment . The method may be performed by a computing device , such as the apparatus 100 . There may be an ongoing charging transaction at a charging station, and the charging transaction may have sent a start-message and one or more meter values to the apparatus 100 . The apparatus 100 may have set the record status of a respective CDR to the in progress -state based on the messages .

[0081] At 500 , the apparatus 100 has received a plurality of consecutive meter values with the same energy reading from the charging station . For example , the apparatus 100 may be configured to wait until a predetermined number of consecutive meter values with the same reading is received, before continuing to operation 502 . The predetermined number may be , for example , 3 meter values , 5 meter values , 10 meter values , 20 meter values , or any other configured number . A plurality of consecutive meter values having the same energy reading (e . g . , 152 kwh, 152 kWh, 152 kWh . . ) may indicate that energy is no longer being delivered to an EV at the charging station even though no stop-message is received for the charging transaction .

[0082] At 502 , the apparatus 100 may be configured to request the charging station to send a latest stopmessage . For example , the apparatus 100 may send a trigger message command to the charging station . The trigger message may be based on the OCPP protocol . With the trigger message , a charging station can be requested to send a certain message , such as the latest stopmessage or a latest status notification .

[0083] At 504 , the apparatus 100 may be configured to determine if the stop-message for the ongoing charging transaction is received from the charging station in response to the request .

[0084] At 506 , if the stop-message is received, the apparatus 100 may be configured to update the CDR record with one or more values determined based on the stopmessage , update the data of the CDR to a confirmed state and the CDR record to a stopped state .

[0085] At 508 , if the stop-message is not received, the apparatus 100 may be configured to request a status notification from the charging station . The status notification may be requested, for example , with the trigger message command .

[0086] At 510 , the apparatus 100 may be configured to determine if the requested status notification is received from the charging station .

[0087] At 512 , if the apparatus 100 determines that the requested status notification is received, the apparatus 100 may be configured to continue with the method described in FIG . 4 .

[0088] At 514 , if the apparatus 100 determines that the requested status notification is not received, the apparatus 100 may be configured to calculate a probability that the charging has been stopped at the charging station .

[0089] The received identical readings ( at 500 ) may indicate an idle time to be used as an estimated value . The estimated idle time may be compared to a typical idle time of the charging station . Charging stations at different locations may have different typical idle times . For example , at an office building people may start charging their EV at 9 AM, battery of the EV may be full after 2 hours , and the people may stop charging at 5 PM when they leave work. The typical idle time at this location would then be 5 hours. For comparison, at an airport location people may start charging when they arrive at the airport, their EV may charge for a few hours, but the people may disconnect their EV after 5 days when they return from their travel. At the airport location, the typical idle time could be 4,8 days (115 hours) . A typical idle time for a charging station may be calculated as a median value of all idle times of the charging station during a last 30 days. The probability for stopped charging may be calculated, for example, as follows :

[0090] 0,30. (1)

[0091] Hence, when calculated with the equation (1) , the probability would be 6 % at the office building when an EV has been idle for 6 hours and the typical idle time is 5 hours. Similarly, the probability would be 64 % at the airport location when an EV has been idle for 360 hours and the typical idle time is 115 hours.

[0092] At 516, the apparatus 100 may be configured to determine if the probability is above a predetermined threshold. For example, the predetermined threshold may be set to 50%, and the probability may have values between 0-100%. The predetermined threshold may have any configured value. The value may be configurable by an operator. For example, if an EV has been idle at the office building for 6 hours instead of typical 5 hours, it may be considered a normal idle time (probability 6 % < 50 %) . However, if the EV would have been idle for 14 hours, the idle time may not seem normal, and the apparatus 100 may suspect that something is wrong (probability 54 % > 50 %) .

[0093] At 518, if the calculated probability is below the predetermined threshold, the apparatus 100 may be configured to wait for a predetermined interval (e.g., 5 minutes ) . Thereafter, the apparatus 100 may return to operation 508 and send again the request for status notification to the charging station . I f the charging station still does not send the requested status notification, the apparatus 100 may be configured to calculate a new probability that the charging has stopped and compare the probability to the predetermined threshold, at 514 and 516 .

[0094] At 520 , if the calculated probabi lity is above the predetermined threshold, the apparatus 100 may be configured to update the CDR record to a suspected stop state . The apparatus 100 may be further configured to update the CDR with one or more estimated values and with an estimate state for the data in the CDR record .

[0095] At 522 , the apparatus 100 may be configured to add the CDR record with the suspected stop state to quarantine .

[0096] FIG . 6 il lustrates an example of a flow chart of a method to correct missing data when a start-message of a new charging transaction is sent before sending a stop-message of a previous charging transaction according to an example embodiment . The method may be performed by a computing device , such as the apparatus 100 . There may be an ongoing charging transaction at a charging station, and the charging station may have sent a start-message and one or more meter values to the apparatus 100 . The apparatus 100 may have set a CDR record to the in progress -state based on the messages .

[0097] At 600 , the apparatus 100 may receive a new start-message from the charging station . The new startmessage may indicate that a new charging transaction has been started at the charging station with a same connector as the previous ( ongoing) charging transaction .

[0098] At 602 , the apparatus 100 may be configured to wait for a predetermined interval for a stop-message from the charging station after the new start-message is received. The predetermined interval may be, for example, 10 minutes. However, the predetermined interval is configurable, and can also have other value, such as 5 minutes, 20 minutes, 1 hour, etc.

[0099] At 604, the apparatus 100 may be configured to check if the stop-message is received within the predetermined interval. If yes, at 606, the apparatus 100 may be configured to update the CDR record to a stopped state and data status in the CDR record to a confirmed state.

[0100] At 608, if the stop-message is not received within the predetermined interval, the apparatus 100 may be configured to request the stop-message from the charging station. The stop-message may be requested, for example, with a trigger message command.

[0101] At 610, the apparatus 100 may be configured to check if the charging station sent the requested stopmessage. If yes, the apparatus may perform the operation 606. If not, the apparatus 100 may be configured to calculate a probability that the charging (associated with the previous charging transaction) has stopped at the charging station, at 612.

[0102] The probability may be calculated based on a time there has been between the new start-message received at 600 and a current moment. It may be normal for a charging station to first send the new startmessage and the stop-message of the previous charging transaction. There may be also a delay after sending the new start-message, before sending the stop-message for the previous charging transaction. For example, a delay of 1-2 minutes for receiving the stop-message may be normal, but if the delay is more than 10 minutes since the new start-message has been received, a fault may be likely, and the previous charging transaction may have been actually stopped. For example, the probability may be calculated as follows: (time since new start-message) - 10

[0103] Probability = (2)

[0104] 10

[0105] For example, if the new start-message was received 11 minutes ago, the probability would be (11-10) / 10=10%, and if the new start-message was received 19 minutes ago, the probability would be (19-10) / 10=90% .

[0106] At 614, the apparatus 100 may be configured to check if the probability is greater than a predetermined threshold (e.g., 50 %) . If not, the apparatus 100 may be configured to wait for a second predetermined interval (e.g., 5 minutes) , at 616. After the second predetermined interval, the apparatus 100 may be configured to repeat the operation 608.

[0107] If the probability is above the predetermined threshold, the apparatus 100 may be configured to update data in the CDR record to an estimate state and with one or more estimated values, at 618. The apparatus 100 may be further configured to update the CDR record to a suspected stop state, at 620. At 622, the apparatus 100 may be configured to add the CDR record to quarantine.

[0108] FIG. 7 illustrates an example of a flow chart of a method for correcting missing data when a charging station is not communicating, according to an example embodiment. The method may be performed by a computing device, such as the apparatus 100. Here, there may be an ongoing charging transaction at a charging station but the charging stations gets disconnected from the apparatus or stops sending messages for some reason. A CDR record for the charging transaction may be stored at the apparatus with an in progress -state.

[0109] At 700, the apparatus 100 may have detected that the charging station is not anymore communicating with the apparatus 100. For example, the charging station may have gone offline due to a disconnected web socket .

[0110] At 702, the apparatus 100 may be configured to wait for a predetermined interval to see if the charging station resumes normal communications . For example , the apparatus 100 may be configured to wait for 5 minutes before checking at 704 if the charging station has started communications . I f the connection is restored, the apparatus 100 may determine at 706 that no further actions are needed .

[0111] I f the communications are not restored after the predetermined interval , the apparatus 100 may be configured to update , at 708 , the CDR record with one or more estimated values . For example , a plugged-in end time may be updated based on a last message that was received from the charging station . Further, an energy value may be updated based on a last value of a latest meter value message received from the charging station . Energy delivery end time may be updated with a timestamp of a last meter values message that comprised a different value than the previous meter values message .

[0112] At 710 , the apparatus 100 may be configured to calculate a probability that the charging station has a fault , and the charging transaction may have stopped . Charging stations may be offline for short periods (e . g . , from few minutes up to few hours ) even when a charging transaction has not stopped . Therefore , the probability for a fault may increase with longer offline periods .

[0113] Charging stations at different locations may have different typical charging times . For example , on a slow home charging station one might typically charge overnight for 8 hours , while on ultra-fast DC (direct current ) charging station a typical charging time might be only 20 minutes . A typical charging time for a charging station may be calculated as a median value of all charging times of the charging station during a certain time period, such as during the last 30 days . The apparatus 100 may estimate a current charging time based on a current time and a start-time obtained from the start-message. The probability may be calculated as follows : „ „„ , „ , 0,30 (3)

[0114] For example, an office building may have a typical charging time of 3 hours. An EV started charging at 11:00 at a charging station, but the charging station went offline at 12:30. At 15:00, the charging station is still offline and it has not sent a stop-message to the apparatus 100. With the equation (3) , the probability that the charging transaction has stopped would be ( ( 4-3 ) / 3 ) * 0 , 3 = 10%, meaning that there is 10% probability that charging has been stopped, even if there is no stop-message received. For another example, if the charging station is still offline at 21:00 and has not sent a stop-message, the probability would be ( (10-3) / 3) *0,3 = 70 %.

[0115] At 712, the apparatus 100 may be configured to check if the calculated probability is greater than a predetermined threshold (e.g., 50 %) . If the probability is lower than the predetermined threshold, the apparatus 100 may return to operation 702 and continue to wait the communications are resumed. If the probability is greater than the predetermined threshold, the apparatus may be configured to update a status of the data in the CDR record to estimate state at 714.

[0116] At 716, the apparatus 100 may be configured to update the status of the CDR record to a suspected stop state .

[0117] At 718, the apparatus 100 may be configured to add the CDR record to quarantine to wait for further analysis .

[0118] FIG. 8 illustrates an example of a flow chart of a method for approving a charge detail record in quarantine according to an example embodiment. The method may be implemented by a computing device , such as the apparatus 100 .

[0119] At 800 , the apparatus 100 may receive a stopmessage for a charging transaction . At 802 , the apparatus 100 may be configured to check i f there i s a CDR for the charging transaction in quarantine . I f there is no CDR in quarantine for the charging transaction, the apparatus 100 may continue normal process at 804 and there is no need to do anything quarantine related .

[0120] At 806 , if there is a CDR in quarantine for the charging transaction, the apparatus 100 may be configured to update latest values from the stop-message to the CDR, therefore replacing the estimated values .

[0121] At 808 , the apparatus 100 may be configured to update data of the CDR to a confirmed state . At 810 , the apparatus 100 may be configured to update the CDR with a record status "stopped" . Thereafter, the apparatus 100 may be configured to remove the CDR from the quarantine .

[0122] FIG . 9 illustrates an example of a user interface for managing charging detail records according to an example embodiment . The user interface 900 may be configured to enable an operator to check and manage CDR records in quarantine . For example , the apparatus 100 may be conf igured to di splay information about the CDR records in quarantine to the operator via the user interface 900 . Further, the apparatus 100 may be configured to receive user inputs via the user interface 900 to manage the information .

[0123] The user interface 900 may be configured to show a summary of the CDR records in the quarantine . The user interface 900 may also be configured to show details of data stored in the CDR records . The data may be shown in response to user inputs received by the apparatus 100 . The data may comprise , for example , at least one of start time , stop time , information on who was charging (e . g . , ID of an EV driver) , used energy, duration of charging, etc . The operator may edit the CDR data and correct manually possible errors .

[0124] The apparatus 100 may be configured to display via the user interface 900 a probability, calculated by the apparatus 100 , that the charging transaction has been stopped . The operator doing the manual inspection could then for example focus on the CDRs with highest probability . The operator can review the different CDR records and decide which of them to approve for invoicing, and which to rej ect . For example , the user interface 900 may be configured to display a list 902 of CDR records in quarantine and at least the probabilities . The user interface 900 may provide means for receiving user inputs . The user interface 900 may comprise , for example, checkboxes 904 for selecting one or more CDR records to be approved or rej ected . The user interface 900 may further comprise selection buttons 906 for approving or rej ecting the selected CDR record ( s ) . Based on the approval or rej ection received from the operator, the apparatus 100 may be configured to update the respective CDR record with an approval status of either "Manual Approval" or "Manual Rej ection" , for example . Hence , managing CDR records with missing data from charging stations may be facilitated and expedited to the operator . Further, estimated values of the missing data may be provided for the user with probability for the stopped charging transaction .

[0125] FIG . 10 illustrates an example of a user interface for managing quarantine rules according to an example embodiment .

[0126] For example , the apparatus 100 may be configured with rules to either rej ect or approve CDR records in quarantine automatically . Hence , the CDR records in quarantine may not need to be manually approved or rej ected by an operator . For example , the apparatus 100 may be configured to automatically approve CDR records that are in quarantine and meet one or more criteria. For example, the apparatus 100 may be configured to automatically (i.e., without user input) to approve CDR records which have energy usage less than a certain amount (e.g., 10 kWh) , duration less than a certain time (e.g., 1 hour) and probability for stopped charging transaction above a certain threshold (e.g., 80 %) .

[0127] For example, an operator may set the one or more criteria to be applied by the apparatus 100 via the user interface 1000. The operator may set different criteria based on which CDR records put to quarantine are either approved or rejected. The criteria may comprise different CDR data parameters. The user interface 1000 may be configured to provide selectable comparison arguments and a selectable value for the parameters. The operator may select from the user interface to apply one of the following comparison arguments, for example: less than a given value (<) , less or equal to a given value (<=) , equal to a given value ( = ) , greater than a given value (>) , or greater than or equal to a given value (>=) . The value may be selected by the operator to any of following parameters, for example: a time the CDR has been in quarantine (e.g., days) , the probability (e.g., 0-100%) , energy charged (e.g., kWh) , duration of the charging transaction (e.g., minutes) , charging station (e.g., identity) , charging station model and / or vendor, start time of the charging transaction (e.g., date) , stop time of the charging transaction (e.g., date) , cost of charging (e.g., euros or other currency) , charging station owner (e.g., company name) . The operator may also add some other rule or parameter via the user interface 1000.

[0128] For example, the operator may have selected from the user interface 1000 to approve any CDR record in quarantine when the CDR record has been in quarantine more than 7 days, the duration of the charging transaction was less than 60 minutes, and the probability that the charging transaction has been stopped is greater than 80 % . After the selections are saved by the operator, the criteria may be stored by the apparatus 100 . The apparatus 1000 may be conf igured to check regularly if the criteria are met for any CDR in quarantine , and then automatically accept or rej ect the CDR .

[0129] For example , it may be known to an operator that a charging station model XX_123 sometimes stops charging transaction after one minute , and then automatically starts a new charging transaction after that . A vendor of the charging station has promised a firmware fix to overcome the problem, but the fix is not ready yet . For this reason, the operator could set a following rule to be applied by the apparatus 100 :

[0130] Criteria : charging station model = XX_123 AND duration <= 2 minutes AND charged energy <= I kWh,

[0131] Action : rej ect CDR record .

[0132] Many charging stations may also randomly fail to send a correct stop-message for a charging transaction, and they may j ust send a start-message when a next charging transaction starts . Therefore , the operator could set a following rule to be applied by the apparatus 100 :

[0133] Criteria : duration >= 15 minutes AND charged energy >= 5 kWh AND probability >= 80 % ,

[0134] Action : approve CDR record .

[0135] The apparatus 100 may be configured to apply different combinations of criteria for approving or rej ecting the CDRs based on selections made by the operator, for example , with the user interface 1000 .

[0136] FIG . 11 illustrates an example of a flow chart of an automatic approval or rej ection process for quarantined charge detail records according to an example embodiment .

[0137] At 1100 , the apparatus 100 may be configured to loop though all CDRs in quarantine to check if criteria set for one or more rules to automatic approval or rejection are met. The rules for automatic approval or rejection may be referred to as automation rules.

[0138] At 1102, the apparatus 100 may be configured to loop though all the automation rules for each of the CDRs in quarantine. At 1104, the apparatus 100 may be configured to check if the criteria set for one of the automation rules match data of the CDR. If the criteria are not met, the apparatus 100 may be configured to check if the automation rule was a last rule, at 1106. If the automation rule was not last, the apparatus 100 may proceed to a next automation rule. If the automation rule was last, the apparatus 100 may proceed to a next CDR record.

[0139] If the criteria of the automation rule are met, the apparatus 100 may be configured to apply the automation rule at 1108. At 1110, the apparatus 100 may determine if the CDR is approved based on the automation rule. If the CDR is not approved, the CDR may be taken out of the quarantine and moved to permanently rejected files at 1112. Once the CDR is rejected by the apparatus 100, the CDR may not be used for invoicing, for example. If the CDR is approved, the CDR may be taken out of the quarantine and the apparatus 100 may update the record status of the CDR to the stopped state, at 1114. The CDR may be then finalized and used for invoicing, for example .

[0140] However, after a CDR record is quarantined due to a missing stop-message and then either approved or rejected, it is possible that a charging station eventually sends the stop-message for the related charging transaction. In an example scenario, the charging station may have gone offline, and stayed offline, while the charging transaction was in progress. The CDR for the charging transaction was quarantined, and after a few days, it was approved because the probability for stopped charging transaction was over 90 % , for example . After the CDR was approved, the CDR was invoiced from an EV driver . After a couple of months , the charging station becomes online again, and sends the correct stop-message to the apparatus 100 . In this situation, the EV driver has been invoiced based on estimated data and later the correct data is received . Therefore , the apparatus 100 may be configured to perform one or more actions when a stop-message of a charging transaction is received after a related CDR record has already been approved or rej ected .

[0141] FIG . 12 illustrates an example of a user interface for late stop-message configuration according to an example embodiment .

[0142] The apparatus 100 may be configured to perform different actions depending on if the CDR was previously approved or rej ected . For example , the apparatus 100 may be configured to ignore the late received stop-message . Alternatively, the apparatus 100 may be configured to update CRD with data from the stop-message . The apparatus 100 may be configured to display a user interface 1200 , wherein an operator can set rules to be applied when a stop-message is received late . The user interface 1200 may be configured to provide user interface elements allowing the user to select whether late stop-messages are used for updating approved / re j ected CDR records or ignored . The user interface 1200 may be further configured to allow the operator to set one or more criteria when to ignore the late stop-message or when to use for updating . The one or more criteria may be based on data parameters of the approved / re j ected CDR, such as duration or energy usage , or a dif ference between the data in the CRD and in the late stop-message .

[0143] For example , if the stop-message is received after the CDR is rej ected, the apparatus 100 can be configured to update the CDR . Further, if the stopmessage is received after the CDR is approved, the apparatus 100 can be configured to ignore the stopmessage and keep the original approved CDR. The apparatus 100 may be further configured to determine an estimate of a difference between the late received stopmessage and done invoicing. For example, at first 8,55 € was invoiced from an EV driver based on estimated usage from the approved CDR. Then the late stop message is received, and based on that the correct amount would have been 8, 90 € . Since the difference is small (0,35 € or 3, 9 %) , the apparatus 100 may be configured to let the driver benefit the lower price and not make a correction .

[0144] If the original CDR was rejected (not invoiced) , the apparatus 100 can be configured to directly update the correct values from the stop-message to the CDR, and update the record status as stopped and approved. For example, a previous quarantined CDR was rejected with the following information: "startTime=2023-04-29 10:02, stopTime=2023-04-29 13:56, energy=142, dataStatus=Estimate, CDRStatus=Suspected stop, quarantineStatus=Re j ected" . At some later point of time the charging station sends a new stop-message with the following information: "stopTime=2023-04-29 15:27, energy=150". The apparatus 100 may update the rejected CDR with information from the stop-message and then provide the CDR for invoicing. The updated CDR could have for example the following information: "startTime = 2023-04-29 10:02, stopTime = 2023-04-29 15:27, energy = 150, dataStatus = Confirmed, CDRStatus = Stopped, quarantinestatus = Approved".

[0145] For example, a previous CDR was approved "startTime = 2023-04-29 10:02, stopTime =2023-04-29 13:56, energy = 142, dataStatus = estimate, CDRStatus = suspected stop, quarantinestatus = Approved". Later, the charging station sends a new stop-message with the following information: "stopTime=2023-04-29 15:27, energy=150". Now, since the CDR had already been approved and invoiced, it may not be changed due to bookkeeping rules. For this reason, the apparatus 100 can be configured to cancel the previous CDR with a negative amount, and a new CDR is created with the correct amount. For example, the cancelling CDR could have the following information: "startTime = 2023-04-29 10:02, stopTime = 2023-04-29 13:56, energy = -142, dataStatus = Estimate, CDRStatus = Suspected stop, quarantinestatus = Approved". The new CDR could then provide the correct information: "startTime = 2023-04- 29 10:02, stopTime = 2023-04-29 15:27, energy = 150, dataStatus = Confirmed, CDRStatus = Stopped, quarantinestatus = Approved".

[0146] FIG. 13 illustrates an example of a method for correction of missing charge detail data according to an example embodiment. The method 1300 may be performed by a computing device, such as the apparatus 100.

[0147] At 1302, the method may comprise receiving a start-message from an electric vehicle charging station. The start-message may indicate that a charging transaction has started at the electric vehicle charging station .

[0148] After the start-message is received, at 1304, the method may comprise detecting an indication that the charging transaction has stopped even when no stopmessage indicating the charging transaction has stopped is being received from the electric vehicle charging station. The indication may be based on at least one of one or more messages received from the electric vehicle charging station, or one or more messages missing from the electric vehicle charging station (in addition to the stop-message) . The indication may be also based on an offline status of the charging station.

[0149] At 1306, the method may comprise determining an estimate value for at least one parameter of the charging transaction based on the one or more received messages. Hence, the at least one parameter may be determined indirectly based on the messages , wherein the parameter would otherwise be determined based on the stop-message .

[0150] At 1308 , the method may comprise calculating a probability that the charging transaction is stopped based on the estimated value and a mean value of the parameter for the electric vehicle charging station .

[0151] At 1310 , the method may comprise updating mi ssing data in a charge detail record of the charging transaction with the at least one estimated value and the probability .

[0152] At 1312 , the method may comprise determining, based on the probability, whether to proceed to processing the charge detail record or to perform at least one action to obtain data for updating the at least one estimated value . For example , if the probability is below a configured threshold, the apparatus may wait for more data from the charging station . Alternatively, or in addition, the apparatus may send a trigger message to the charging station requesting for more data . I f the probability is above the configured threshold, the apparatus may approve the CDR or put the CDR to quarantine . The apparatus 100 may then determine based on at least one of the estimated value or the probability if the charge detail record in quarantine is approved or rej ected for further processing .

[0153] It is obvious to a person skil led in the art that with the advancement of technology, the basic idea of the invention may be implemented in various ways . The invention and its embodiments are thus not limited to the examples described above , instead they may vary within the scope of the claims .

[0154] Further features of the methods directly result from the functionalities and parameters of the apparatus as described in the appended claims and throughout the specification and are therefore not repeated here . It is noted that one or more operations of the method may be performed in different order .

[0155] An apparatus may be configured to perform or cause performance of any aspect of the method ( s ) described herein . Further, a computer program may comprise instructions for causing, when executed, an apparatus to perform any aspect of the method ( s ) described herein . Further, an apparatus may comprise means for performing any aspect of the method ( s ) described herein . According to an example embodiment , the means comprises at least one processor , and memory including program code , the at one memory and the program code configured to, when executed by the at least one processor, cause performance of any aspect of the method ( s ) .

[0156] Any range or device value given herein may be extended or altered without losing the effect sought . Also , any embodiment may be combined with another embodiment unless explicitly disallowed .

[0157] Although the subj ect matter has been described in language specific to structural features and / or acts , it is to be understood that the subj ect matter defined in the appended claims is not necessarily limited to the specific features or acts described above . Rather, the specific features and acts described above are disclosed as examples of implementing the claims and other equivalent features and acts are intended to be within the scope of the claims .

[0158] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments . The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages . It will further be understood that reference to ' an ' item may refer to one or more of those items . The operations of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the embodiments described above may be combined with aspects of any of the other embodiments described to form further embodiments without losing the effect sought.

[0159] The term 'comprising' is used herein to mean including the method, blocks, or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

[0160] As used in this application, the term 'circuitry' may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable) : (i) a combination of analog and / or digital hardware circuit (s) with sof tware / f irmware and (ii) any portions of hardware processor (s) with software (including digital signal processor ( s ) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit (s) and or processor ( s ) , such as a microprocessor ( s ) or a portion of a microprocessor ( s ) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term in this application, including in any claims.

[0161] As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its ( or their) accompanying software and / or firmware . The term circuitry also covers , for example and if applicable to the particular claim element , a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device , or other computing or network device .

[0162] It will be understood that the above description is given by way of example only and that various modifications may be made by those skilled in the art . The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments . Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments , those skilled in the art could make numerous alterations to the disclosed embodiments without departing from scope of this specification .

Claims

CLAIMS1 . An apparatus ( 100 ) for managing missing charge data, the apparatus comprising : at least one processor ( 102 ) ; and at least one memory ( 104 ) comprising instructions which, when executed by the at least one processor, cause the apparatus at least to : receive a start-message from an electric vehicle charging station ( 200 ) indicating a charging transaction has started; after the start-message is received, detect an indication that the charging transaction has stopped, without a stop-message indicating the charging transaction has stopped being received from the electric vehicle charging station, wherein the indication is detected based on one or more messages at least one of received or missing from the electric vehicle charging station, characterised in that, the apparatus is further caused to ; determine an estimate value for at least one parameter of the charging transaction based on the one or more received messages ; calculate a probability that the charging transaction is stopped based on the estimated value and a mean value of the parameter for the electric vehicle charging station ; update missing data in a charge detail record ( 202 ) of the charging transaction with the at least one estimated value and the probability; and determine , based on the probability, whether to proceed to processing the charge detail record or to perform at least one action to obtain data for updating the at least one estimated value .2 . The apparatus ( 100 ) of claim 1 , wherein the at least one memory ( 104 ) further comprises instructionswhich, when executed by the at least one processor ( 102 ) , cause the apparatus to : update a data status of the charge detail record ( 202 ) to indicate the charge detail record comprises at least one estimated value ; update a record status of the charge detail record to indicate the charging transaction is suspected to have stopped; if the stop-message is received, replace the at least one estimated value with a value determined based on the stop-message and update the data status to indicate the charge detail record comprises confirmed values and the record status of the charge detail record to indicate the charging transaction has stopped; and perform processing of the charge detail record based on the data status and the record status .3 . The apparatus ( 100 ) of claim 1 or 2 , wherein the at least one memory ( 104 ) comprises instructions which, when executed by the at least one memory, cause the apparatus to : monitor meter value messages received from the electric vehicle charging station ( 200 ) ; detect the indication that the charging transaction has stopped based on a plurality of consecutive meter value messages having a same energy reading; determine an estimated energy usage based on a latest received meter value message .4 . The apparatus ( 100 ) of claim 3 , wherein the at least one memory ( 104 ) further comprises instructions which, when executed by the at least one processor ( 102 ) , cause the apparatus to : determine an estimated end of energy delivery time based on a last meter value message having adifferent energy reading than a preceding meter value message .5 . The apparatus ( 100 ) of any preceding claim, wherein the at least one memory ( 104 ) comprises instructions which, when executed by the at least one processor ( 102 ) , cause the apparatus to : monitor status notifications received from the electric vehicle charging station ( 200 ) ; detect the indication that the charging transaction has stopped based on a status notification indicating an unplugged electric vehicle and wherein the stop-message is not received within a predetermined interval from the status notification ; and determine an estimated idle time of the charging transaction based on a time of a last received meter value message having a different energy reading than a preceding meter value message from the electric vehicle charging station and a timestamp of the status notification ; determine the probability based on the estimated idle time and a mean value of an idle time at the electric vehicle charging station .6 . The apparatus ( 100 ) of any preceding claim, wherein the at least one memory ( 104 ) comprises instructions which, when executed by the at least one processor ( 102 ) , cause the apparatus to : put the charge detail record ( 202 ) to quarantine when the probability is above a predetermined threshold; and rej ect or approve the charge detai l record in quarantine for further processing based on one or more criteria ; and remove the rej ected or approved charge detail record from the quarantine .7 . The apparatus ( 100 ) of any of claims 3 to 6 , wherein the at least one memory ( 104 ) comprises instructions which, when executed by the at least one processor ( 102 ) , cause the apparatus to : after detecting the plurality of consecutive meter value messages having the same energy reading, send a first trigger message to the electric vehicle charging station ( 200 ) requesting a latest stop message ; if the stop-message for the charging transaction is received in response to the first trigger message , update at least one of the at least one estimated value with a value determined based on the stop-message, a data status of the charge detail record ( 202 ) to indicate the charge detail record comprises confirmed values or a record status of the charge detail record to indicate the charging transaction has stopped; if the stop-message is not received in response to the first trigger message , send a second trigger message to the electric vehicle charging station requesting a latest status notification ; if a status notification is not received from the electric vehicle charging station in response to the second trigger message , calculate the probability; if the probability is below the predetermined threshold, resend the second trigger message after a second predetermined interval ; and if the probability is above until the predetermined threshold, put the charge detail record to quarantine .8 . The apparatus ( 100 ) of any preceding claim, wherein the at least one memory ( 104 ) comprises instructions which, when executed by the at least one processor ( 102 ) , cause the apparatus to : receive a second start-message from the electric vehicle charging station ( 200 ) indicating a new charging transaction has started;detect that the stop-message for the previous charging transaction is not received within a third predetermined interval after the second start-message ; send a first trigger message for the electric vehicle charging station requesting for a latest stopmessage ; if the stop-message is received in response to the first trigger message , update at least one of the at least one estimated value with a value determined based on the stop-message , the data status of the charge detail record ( 202 ) to indicate the charge detail record comprises confirmed values or the record status of the charge detail record to indicate the charging transaction has stopped; if the stop message is not received in response to the first trigger message , calculate the probability; if the probability is above the predetermined threshold, put the charge detail record to quarantine .9 . The apparatus ( 100 ) of any preceding claim, wherein the indication is detected when at least one of one or more messages expected from the electric vehicle charging station ( 200 ) are not received within a fourth predetermined interval or when the electric vehicle charging station is offline for the fourth predetermined interval ; and wherein the at least one memory ( 104 ) comprises instructions which, when executed by the at least one processor ( 102 ) , cause the apparatus to : update the charge detail record ( 202 ) with at least one of an estimated plugged-in end time based on a timestamp of a last message received from the electric vehicle charging station, an estimated energy value based on an energy reading of a last received meter value message , or an estimated energy delivery end time based on a timestamp of a last meter value message that had a different energy reading than a preceding meter value message ;determine an estimate of a current charging time based on a start-time from the start-message and a current time ; calculate the probability based on the current charging time and a mean value for a charging time at the electric vehicle charging station ; if the probability is less than the predetermined threshold, wait the fourth predetermined interval if the electric vehicle charging station sends the expected message or becomes online , and if the electric vehicle charging station is still faulted, update the charge detail record with the at least one estimated value and recalculate the probability; if the probability is above the predetermined threshold, put the charge detail record to quarantine .10 . The apparatus ( 100 ) of any of claims 6 to 9 , wherein the at least one memory ( 104 ) comprises instructions which, when executed by the at least one processor ( 102 ) , cause the apparatus to : detect that a stop-message associated to a charge detail record ( 202 ) in quarantine , approved or rej ected is received; check configuration for late received stopmessages ; based on the configuration, either update at least one of the at least one estimated value based on the stop-message , a data status of the charge detail record values to confirmed or a record status of the charge detail record to indicate the charging transaction has stopped, or ignore the stop-message ; and if the charge detail record is updated, approve the charge detail record for further processing .11 . The apparatus ( 100 ) of any of claims 6 to10 , wherein the at least one memory ( 104 ) comprisesinstructions which, when executed by the at least one processor (102) , cause the apparatus to: output a list of charge detail records (202) in quarantine to a user with the at least one estimated value and the probability; receive a user input indicating one or more charge detail records in the quarantine to be approved or rejected.

12. The apparatus (100) of any of claims 6 to 10, wherein the one or more criteria comprise at least one of a limit for energy usage, a duration of charging transaction, a limit for the probability, a quarantine time, an identity of the electric vehicle charging station (200) , a model of the electric vehicle charging station, a vendor of the electric vehicle charging station, a start time of the charging transaction, an end time of the charging transaction, cost of the charging transaction, an owner of the electric vehicle charging station, or a criterion set by a user.

13. The apparatus (100) of claim 6, wherein the at least one memory (104) comprises instructions which, when executed by the at least one processor (102) , cause the apparatus to: receive the stop-message from the electric vehicle charging station (200) after the charge detail record (202) put to quarantine is approved or rejected; and update the at least one estimated value of the rejected charge detail record based on the stop-message and approve the charge detail record for further processing .

14. A computer-implemented method (1300) , compr srng :receiving ( 1302 ) a start-message from an electric vehicle charging station indicating a charging transaction has started; after the start-message is received, detecting ( 1304 ) an indication that the charging transaction has stopped without a stop-message indicating the charging transaction has stopped being received from the electric vehicle charging station, wherein the indication is detected based on one or more messages at least one of received or missing from the electric vehicle charging station, characterised in that, the method further comprises ; determining ( 1306 ) an estimate value for at least one parameter of the charging transaction based on the one or more messages ; calculating ( 1308 ) a probability that the charging transaction is stopped based on the estimated value and a mean value of the parameter for the electric vehicle charging station ; updating ( 1310 ) missing data in a charge detail record ( 202 ) of the charging transaction with the at least one estimated value and the probability; and determining ( 1312 ) , based on the probability, whether to proceed to processing the charge detail record or to perform at least one action to obtain data for updating the at least one estimated value .15 . A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method ( 1312 ) of claim 14 .

Images