A scalable approach to handling failures in electric vehicle charging station networks

Abstract

Example embodiments enable a scalable method (200) to manage failures of a large-scale electric vehicle charging station network including even thousands of electric vehicle charging stations. When possible, the failures that occur can be automatically resolved. The failures can be prioritized based on one or more criteria. Methods (200) and apparatus (600) are provided to more effectively handle the failures.

Description

Technical Field

[0001] The present application generally relates to electric vehicle charging stations. In particular, some example embodiments of the present application relate to fault management of an electric vehicle charging station network. Background Art

[0002] Electric vehicle charging stations sometimes have faults due to different reasons. The fault may cause the charging station to stop working, or the charging station may not work properly. Dealing with the fault may take up a lot of resources. Therefore, it would be beneficial to mitigate at least some of these disadvantages. Summary of the invention

[0003] This Summary is provided to introduce some 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 subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] Example embodiments may enable more efficient and rational management of faults at electric vehicle charging stations.The proposed method is particularly useful for managing faults at a network of thousands of electric vehicle charging stations, where, for example, hundreds of faults may occur per day.

[0005] According to a first aspect, a method for managing faults of an electric vehicle charging station is provided. The method is performed by a device, and the method includes: detecting a trigger for calculating a fault priority index for at least one electric vehicle charging station; determining one or more fault indicators, the fault indicators including at least one of the following: the duration of an offline state within a predetermined interval at the electric vehicle charging station, the frequency of the offline state, the duration of a fault, the frequency of the fault, or the number of rejected commands; determining the fault priority index by combining the values ​​of the one or more fault indicators; and initiating at least one action to manage the fault at the at least one charging station based on the fault priority index.

[0006] In one embodiment, the trigger includes at least one of: an indication that the electric vehicle charging station is offline, a fault status notification from the electric vehicle charging station, a rejection of a command by the electric vehicle charging station, a failure of the electric vehicle charging station to respond to a command, or a return of the electric vehicle charging station to a normal state.

[0007] In one embodiment, additionally or alternatively, the frequency of the offline state is determined based on a total duration of the offline state of the electric vehicle charging station within a predetermined interval.

[0008] In one embodiment, additionally or alternatively, the frequency of the faults is determined based on a total duration of faults of the electric vehicle charging station within a predetermined interval.

[0009] In one embodiment, additionally or alternatively, the at least one action includes at least one of: providing a list of electric vehicle charging stations in order of urgency based on a fault priority index, providing recommendations on how to repair a fault, restarting the electric vehicle charging station, performing a firmware update on the electric vehicle charging station, resetting the Internet connection of the charging station, alerting remote maintenance, or alerting on-site maintenance.

[0010] In one embodiment, additionally or alternatively, the method further includes: determining a priority level of the fault priority indicator based on a plurality of priority levels having different predetermined thresholds for the fault priority indicator; and initiating at least one action based on the priority level of the fault priority indicator.

[0011] In one embodiment, additionally or alternatively, the method further includes: after executing the at least one action, updating the fault priority indicator of the electric vehicle charging station; if the updated fault priority indicator indicates that the fault still exists, initiating another action according to the priority of the fault priority indicator.

[0012] In one embodiment, additionally or alternatively, the method further includes: grouping a plurality of electric vehicle charging stations into a plurality of sub-groups; grouping the plurality of sub-groups into one or more parent groups; determining an escalation index for each group by multiplying the number of faulty electric vehicle charging stations in the group by the sum of the fault priority indicators in the group, and dividing the value by the number of non-faulty electric vehicle charging stations in the group; and providing a notification to a contact of the parent group when the escalation index exceeds a predetermined limit of the sub-group.

[0013] According to a second aspect, a device for managing faults of an electric vehicle charging station is provided, the device comprising at least one processor; and at least one memory comprising program code, the program code being configured to, together with the at least one processor, enable the device to at least: detect a trigger for calculating a fault priority index of at least one electric vehicle charging station; determine one or more fault indicators, the one or more fault indicators comprising at least one of: the duration of an offline state within a predetermined interval at the electric vehicle charging station, the frequency of the offline state, the duration of the fault, the frequency of the fault, or the number of rejected commands; determine the fault priority index by combining the values ​​of the one or more fault indicators; and based on the fault priority index, initiate at least one action to manage the fault at the at least one charging station.

[0014] In one embodiment, the trigger includes at least one of: an indication that the electric vehicle charging station is offline, a fault status notification from the electric vehicle charging station, a rejection of a command by the electric vehicle charging station, a failure of the electric vehicle charging station to respond to a command, or a return of the electric vehicle charging station to a normal state.

[0015] In one embodiment, additionally or alternatively, the at least one action includes at least one of: creating a list of electric vehicle charging stations in order of urgency based on the fault priority indicator, providing recommendations on how to repair the fault, restarting the electric vehicle charging station, performing a firmware update on the electric vehicle charging station, resetting the Internet connection of the charging station, alerting remote maintenance, or alerting on-site maintenance.

[0016] In one embodiment, additionally or alternatively, the at least one memory also includes program code, which is configured to utilize the at least one processor to enable the device to: determine the priority level of the fault priority indicator based on multiple priority levels with different predetermined thresholds for the fault priority indicator; and initiate at least one action based on the priority level of the fault priority indicator.

[0017] In one embodiment, in addition or alternatively, the at least one memory also includes a program code, which is configured to use the at least one processor to enable the device to: update the fault priority indicator of the electric vehicle charging station after the at least one action; if the updated fault priority indicator indicates that the fault still exists, initiate another action based on the priority level of the fault priority indicator.

[0018] In one embodiment, additionally or alternatively, the at least one memory also includes program code configured to utilize at least one processor to cause the device to: group a plurality of electric vehicle charging stations into a plurality of sub-groups; group the plurality of sub-groups into one or more parent groups; determine an upgrade index for each group by: multiplying the number of faulty electric vehicle charging stations in the group by the sum of the fault priority indicators in the group, and dividing the value by the number of non-faulty electric vehicle charging stations in the group; and provide a notification to a contact of the parent group when the upgrade index exceeds a predetermined limit of the sub-group.

[0019] According to a third aspect, there is provided a computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the method of the first aspect.

[0020] Many of the accompanying features will be more readily appreciated as the same become better understood by reference to the following detailed description considered in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0022] Figure 1 illustrates an example of a fault management system for an electric vehicle charging station network according to an example embodiment;

[0023] Figure 2 illustrates an example of a flow chart of a method for managing failures of an electric vehicle charging station network according to an example embodiment;

[0024] Figure 3 An example of a flow chart of a process for generating a maintenance alert according to an exemplary embodiment is shown;

[0025] Figure 4 shows an example configuration of actions taken based on a threshold of a fault priority indicator according to an example embodiment;

[0026] Figure 5 An example of a hierarchical model of an electric vehicle charging station network for creating maintenance alerts according to an example embodiment is shown;

[0027] Figure 6 An example of an apparatus configured to implement one or more example embodiments is illustrated.

[0028] In the drawings, the same reference numerals may be used to denote the same components. DETAILED DESCRIPTION

[0029] 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 conjunction with the accompanying drawings is intended as a description of examples of the present invention and is not intended to represent the only form in which examples of the present invention may be constructed or utilized. The description sets forth the functions of the example and possible sequences of operations for constructing and operating the example. However, the same or equivalent functions and sequences may be implemented by different examples.

[0030] An electric vehicle charging station (CS) is used to charge an electric vehicle (EV). In the present disclosure, an electric vehicle charging station may be referred to as a charging station. The charging station may be connected to a charging station management system (CSMS) using an OCPP protocol (Open Charge Point Protocol). EV drivers own electric vehicles (EVs) and charge their EVs at charging stations.

[0031] Charging stations often have different technical faults. In a large charging station network that may include thousands or even tens of thousands of charging stations, there may be at least hundreds or sometimes even thousands of charging stations that are interrupted at the same time for some reason.

[0032] Manually handling faults by a central organization is quite expensive. For example, managing and resolving faults at more than 1,000 charging stations per day would require a large team of personnel, and in order to manage the faults globally, would result in a large and expensive arrangement to manually handle all faults.

[0033] In order to manage the network, information may be needed about which charging stations have faults, what the faults are, how to correct the faults, and whether the faults have been corrected. For example, for each fault, a ticket can be created, and the support staff can then check each ticket. However, when there are thousands of charging stations, a ticketing system may result in too much work. Creation of tickets can also be automatic, where each charging station has a responsible maintenance person, and a ticket is automatically created for that person for each fault. However, in practice, there may be too many tickets and many false alarms. Therefore, it may be easy for people to start ignoring the tickets and alarms. Sometimes maintenance staff forget to keep the tickets updated, making it difficult to know which charging stations actually have faults and which have been repaired.

[0034] The charging station may also automatically restart when it sends a fault alert. This may solve some problems, but not all. Additionally, the charging station may be offline so it cannot be restarted remotely, or the charging station may not even send an alert that would otherwise trigger a restart.

[0035] Typically, a fault in a charging station can be detected in three standard ways. In a first approach, for example, a fault can be detected based on a disconnected WebSocket connection. When the websocket connection is disconnected, the charging station may have lost connection to the CSMS and is offline. In addition, a fault can be detected based on a missing heartbeat (i.e., a periodic signal generated by the charging station indicating normal operation and / or for synchronization). When one or more heartbeats / signals are lost, the charging station may no longer communicate, even if the WebSocket is open. In addition, a fault can be detected based on a status notification received from the charging station, which has a fault state indicating that the charging station is faulty.

[0036] However, the above detection method has two problems. Charging stations often send many status notifications, such as even thousands of status notifications a day. In addition, faults reported by charging stations are often automatically resolved. Therefore, it may not be reasonable to always warn maintenance personnel about each individual fault or offline period. In addition, it is common that a charging station is online and sends heartbeats, and has not sent any fault notifications, but still for some reason, the charging station cannot charge.

[0037] One object is to provide an automated system for notifying and managing faults at an electric vehicle charging station. The method may enable tracking of which faults have been automatically resolved and which have not been automatically resolved.

[0038] In an embodiment, a fault may be noticed even when the charging station has not yet sent a fault message. In an embodiment, an alert about a fault may be created in a hierarchical manner. Thus, the faults may be prioritized so that the faults that require attention first may be handled before less critical faults if the faults are not automatically resolved. The method may improve the performance of an electric vehicle charging station network with improved fault management.

[0039] Figure 1 An example of a fault management system for an electric vehicle charging station network 100 according to an example embodiment is illustrated. The network 100 may include hundreds of charging stations. In an embodiment, the network 100 may include at least one thousand charging stations. In an embodiment, the network 100 may include hundreds of thousands of charging stations.

[0040] Each charging station may be communicatively coupled to CSMS server 102. CSMS server 102 may be configured to perform one or more actions based on triggers received from network 100. CSMS server 102 may be configured to determine a fault priority indicator for each charging station based on triggers received from the corresponding charging station.

[0041] One or more actions may be performed based on the fault priority index. The fault priority index may be used by the CSMS server 102 to prioritize some faults over other faults. The faults may be prioritized so that instead of reporting each fault 104 to the maintenance 106, only those faults that are determined to require attention from the maintenance reason for creating the notification are reported. The notification may be created after an automatic action initiated by the CSMS server 102 has not resolved the fault and when the fault priority index exceeds a predetermined threshold. Thus, maintenance of the network 100 may be automated and accelerated because the number of alarms requiring attention of the maintenance personnel 106 may be reduced and focused based on their urgency.

[0042] Figure 2 An example of a flow chart of a method 200 of managing failures of an electric vehicle charging station network is illustrated according to an example embodiment.

[0043] At 202, the method may include detecting a trigger for calculating a fault priority index for at least one electric vehicle charging station. In one embodiment, the trigger may be obtained from a healthy charging station, indicating that the charging station has gone offline or has some other type of fault. A healthy charging station may refer to a charging station that is online and working as it should, i.e., there are no faults. In an embodiment, the trigger may be obtained from a faulty charging station, indicating that the charging station has recovered. This means that the charging station may have returned to online and it is no longer faulty, i.e., it is working as it should.

[0044] At 204, the method may include determining one or more fault indicators. The fault indicators may include at least one of the duration of an offline state within a predetermined interval at the electric vehicle charging station, the frequency of the offline state, the duration of faults, the frequency of faults, or the number of rejected commands.

[0045] The offline duration may give information about how long the corresponding charging station has been offline. The fault duration may give information about how long the corresponding charging station has been in a faulty state. For example, the duration may be measured in minutes. In an embodiment, the trigger may be used to calculate the duration. For example, the calculation of the duration may start in response to a first trigger indicating a fault and stop in response to a second trigger indicating a recovery.

[0046] The offline frequency may give information about how long the charging station has been offline in total during a predetermined time period (e.g., during the last 7 days). The fault frequency may give information about how many faults the charging station reported during a predetermined time period, such as during the last 7 days. In an embodiment, the number of faults may be determined based on triggers, such that a first trigger received after receiving a second trigger may indicate a new fault.

[0047] The number of rejected commands may give information about how many commands (e.g., OCPP commands) sent to the charging station, for example, by the CSMS, have been rejected by the charging station or have no response at all. The number of rejected commands may be compared with the number of commands accepted during a predetermined time period (e.g., the last 7 days).

[0048] At 206, the method may include determining the fault priority indicator by combining the values ​​of the one or more fault indicators. The fault priority indicator may be calculated for each charging station in the network. In an embodiment, the fault priority indicator may have a value in the range of 0-100, where 100 indicates the most urgent problem. However, this range is only an example. In an embodiment, the calculation may also be triggered when a charging station previously indicated as faulty or offline returns to a normal state, i.e., the charging station may have sent a notification of a normal (non-faulty) state, or it is online again.

[0049] Based on the fault priority index, it can be determined how urgent the fault is. For example, if the charging station has been offline for only five minutes, it may not be an urgent problem yet, and it may be necessary to wait for a while before starting an investigation into the problem. Therefore, the total fault priority index may include a value determined based on the offline duration (the time from offline to the current time). For example, if the charging station has been offline for less than ten minutes, the fault priority index of the fault indicator may be 0 points. If the charging station has been offline for more than 24 hours, the fault priority index of the fault indicator may be 20 points. Other points from 1 to 19 can be determined linearly between the minimum (e.g., 10 minutes) and maximum (e.g., 24 hours) time periods. This is just an example, and the points and time limits are configurable.

[0050] The offline frequency may indicate whether the fault is the first problem or whether the charging station has also had problems before. The more problems a charging station has, the more urgent the fault may be. The fault priority index of the offline frequency may be calculated by adding together the duration of all offline periods during a predetermined time period and calculating the offline percentage, where the offline percentage = offline duration minutes / total minutes in the predetermined time period. For example, if the offline duration is less than 1%, the fault priority index value may be 0 points. If the offline duration is greater than 80%, the fault priority index value may be, for example, 20 points. Other points may be calculated linearly between the minimum (1%) and maximum (80%) offline durations. This is just an example, and the point and percentage limits are configurable.

[0051] The duration of the fault can indicate the urgency of the fault. For example, if the charging station has been faulty for only five minutes, it may not be an urgent problem yet. Therefore, it may be necessary to wait for a period of time before an investigation into the problem can be started. The total fault priority index may include a value determined based on the duration of the most recent fault period (the time from the fault state to the fault-free state). For example, if the charging station has been faulty for less than ten minutes, the fault priority index of the fault indicator may be 0 points. If the charging station has been faulty for more than 24 hours, the fault priority index of the fault indicator may be, for example, 20 points. Other points between 0 and 20 points can be determined linearly between the minimum (10 minutes) and maximum (24 hours) time periods. This is just an example, and the points and time limits are configurable.

[0052] The fault frequency may indicate whether the fault is the first problem or whether the charging station has also had problems before. The more problems a charging station has, the more urgent the fault may be. The fault priority index of the fault frequency may be calculated by adding together the duration of all fault periods during a predetermined time period and calculating the failure percentage, where offline percentage = failure duration minutes in a predetermined time period / total minutes. For example, if the fault duration is less than 1%, the fault priority index value may be 0 points. For example, if the fault duration has exceeded 80%, the fault priority index value may be 20 points. Other points may be calculated linearly between the minimum (1%) and maximum (80%) fault durations. This is just an example, and the point and percentage limits are configurable.

[0053] Even if the charging station is online and has not yet sent any fault notifications, it may still fail. For example, if the charging station does not respond to some messages, it can be determined that the charging station is not working as it should. For example, the charging station may not respond to key OCPP messages such as "Authorize Charging", "Start Charging", and "Stop Charging". A fault priority index value for the number of rejected commands can be calculated by adding together all unanswered and rejected messages within a predetermined time period. In one embodiment, the fault priority index value can be determined based on the number of unanswered and / or rejected messages of a specific critical message type. If the total count is greater than 50 messages, the fault priority index value can be, for example, 20 points. If the total number of messages is less than 5, the fault priority index value can be, for example, 0 points. For example, for message counts between 5 and 50 messages, other points from 1 to 19 can be calculated linearly. This is just an example, and the points and limits of messages are configurable.

[0054] At 208, the method may include initiating at least one action based on the fault priority indicator. The at least one action may include sending one or more commands configured to restart or change one or more settings at the charging station. At least some of the commands may be sent automatically. If such remote action does not resolve the issue, the next action may be to send a message to maintenance personnel for further investigation.

[0055] Different alerts can be handled in different ways. The alert can refer to a failure priority indicator that was created or updated. One option is to do nothing (e.g. wait and see how the situation develops). This may be the case for a low priority alert, for example. A low priority alert may refer to an updated failure priority indicator that is below a certain threshold. A low priority alert may be caused by some random error that goes away on its own and may not require interaction.

[0056] Another option is to use some automatic action. In many cases, restarting the charging station helps to correct the fault. In addition to restarting, for example, a firmware update to the latest firmware version can help overcome the problem. In addition, the automatic action can include sending a "cancel location" message to the SIM card of the charging station to reset the Internet connection of the charging station.

[0057] After performing one or more automatic actions, the method may include determining whether manual action is required. If so, the method may include creating a ticket for a remote maintenance personnel or an on-site maintenance personnel in a hierarchical manner.

[0058] For example, a restart may be attempted first, and if the restart does not resolve the fault, the method may include: trying a remote firmware update next time. If this does not help, the method may include: trying to reset the Internet connection. A further option is to alert remote maintenance. For example, some faults may be caused by invalid configurations, old firmware versions, etc., which can be resolved remotely by maintenance personnel. A further option is to alert on-site maintenance. For example, when something is physically damaged, it may be necessary to alert maintenance personnel to replace one or more parts of the charging station or perform other maintenance tasks on-site.

[0059] The fault priority indicator may be updated each time a new trigger is detected. The method may comprise providing an updated report of the charging stations in the network. The report may comprise the charging stations in a fault priority order based on the fault priority indicator, such that the charging station with the highest fault priority indicator is the first charging station. Thus, the report indicates the most urgent faults. This may help maintenance personnel to choose which alarms they should react to. The report may further comprise information about which company owns the charging station and who is the maintenance contact.

[0060] The report may include detailed information about the charging stations, such as their owners and contacts. The user may select any of the reported charging stations to view more details about individual faults. The detailed fault report may include, for example, basic information about the charging station, such as the name, location, company, contact information, POI (point of interest) information, etc. The report may show in detail what the fault priority index comes from (fault indicators), how severe the problem is, and possible actions required to resolve these problems.

[0061] Example embodiments may enable manual work to be avoided as much as possible through automatic actions. In addition, when manual work is required, the work can be widely distributed so that it can be performed as close as possible to the location where the failure can be manually repaired. For example, a global platform company may operate in dozens of different countries. When a high priority alert is received from a country, the centralized personnel of the platform company may not be able to solve the problem. Therefore, based on the report, it can be determined from which country the fault information was received, which company the faulty charging station is associated with, which location of the company, and if possible, directly alert the maintenance personnel at that location to check what is wrong with the charging station. A high priority alert may refer to an updated fault priority indicator that is above a certain threshold.

[0062] For example, the report may show problems with a selected charging station within a selected time interval (e.g., 1.1.2022-7.1.2022). The report may show that the charging station has, for example, three faults within that time. The first problem may be that the charging station is offline, which may be marked as a high priority fault. The report may show details about the event, such as that the charging station has been offline 73% during the last seven days. In addition, the report may show recommended actions based on the fault type and its priority. The second problem may be a medium priority fault, and the details may show that the charging station has had a poor GSM signal 15 times within the selected time. Similarly, the report may show recommended actions based on the faults and their priorities. The third problem may be a low priority fault. The details may show that the charging station has reported a connector lock fault twice within the selected time interval. If, based on the fault type and priority, the low priority fault does not currently require any action, then the low priority fault may not have a recommended action.

[0063] When a charging station has some faults, it may become worse and worse over time. On the other hand, some maintenance actions (such as firmware updates) may improve the situation. Therefore, it may be beneficial to follow the fault trend instead of just following the current situation. Each trigger may be associated with a timestamp. The fault trend may enable tracking of the overall status and direction of the entire network. The fault trend of the network may be determined by summing all fault priority indicator values ​​from all charging stations in the network over a given time period based on the timestamp. Each trigger may be associated with a timestamp. Alternatively or in addition, the fault trend of an individual charging station may be tracked by summing the fault priority indicator values ​​of the individual charging station over a given time period. In one embodiment, the method may include providing such a fault trend for display to a user.

[0064] In one embodiment, the automatic actions may be performed hierarchically. The method may include determining a plurality of priorities and corresponding actions for different priorities based on the fault priority index value. The actions dedicated to the corresponding priorities may also be in a hierarchical order, such that if the first action does not solve the problem (reduce the fault priority index), the next action may be performed, and so on.

[0065] Figure 3 An example of a flow diagram of a process 300 for creating a maintenance alert is shown in accordance with an exemplary embodiment.

[0066] At 302, the method may include determining a current fault priority indicator for the charging station. Based on the current fault priority indicator, the method may include determining a priority level for the charging station. The method may include configuring multiple priority levels with different thresholds for multiple fault priority indicators. Based on the priority level, the method may include determining whether one or more actions should be performed, and what those actions are.

[0067] Figure 4 An example configuration 400 of actions taken based on thresholds of a fault priority indicator according to an example embodiment is shown. The priority levels and corresponding actions may be configured by a user. Thus, different needs and practices of different entities, such as different service levels, may be considered. In an embodiment, the method may include, at 304, determining a group to which the charging station belongs, and determining an action to be performed based on the configuration of the thresholds and corresponding actions for the group.

[0068] For example, a fault priority indicator having a value of 0-4 points (0-4 points out of 100 points) may be at the lowest priority level, which may not require action. A second priority level may be determined for a fault priority indicator of 5 to 25 points. At the second priority level, the method may include performing a first automatic action, which may be restarting the charging station. A third priority level may be determined for a fault priority indicator of 25 to 59 points. At the third priority level, the method may include performing a first automatic action. If the first automatic action does not fix the fault, a remote maintenance personnel may be alerted to the problem. A fourth priority level may be determined for a fault priority indicator of 50 to 79 points. At the fourth priority level, the automatic action may include a first and a second automatic action. The second automatic action may include performing a remote firmware update if a newer firmware version exists. If the first and second automatic actions do not solve the problem, the problem may be reported to remote maintenance. A fifth priority level may be determined for a fault priority indicator of 80-100 points. At the fifth priority level, the automatic action may include the first, the second automatic action, and the third automatic action. The third automatic action may include resetting the Internet connection of the charging station. For example, the method may include: in response to an alarm, performing each of the automatic actions. Or, for example, the automatic actions may be executed one by one until the problem is fixed, or until each automatic action is executed but does not fix the problem, and the alert is forwarded to remote or local maintenance.

[0069] At 306, the method may include calculating a new fault priority index value after the automatic action. At 308, the method may include determining whether the new fault priority index value still requires maintenance action. For example, if the priority level has not changed, another automatic action configured for that priority level may be performed at 310. If no automatic action fixes the fault, the problem may be reported to remote maintenance. If this does not help, the problem may be reported to local maintenance. Figure 4 As shown in the example of , if the configured automatic actions are not sufficient to solve the problem, only the problems with higher priority levels can be notified to remote or on-site maintenance. Thus, only the most urgent problems that cannot be solved automatically or remotely are reported for on-site maintenance.

[0070] Figure 5 An example of a hierarchical model of an electric vehicle charging station network 500 for creating maintenance alerts is shown in accordance with an exemplary embodiment.

[0071] Each electric vehicle charging station can belong to one or more groups 502, 504, 506, 508, 510, 512, 514. These groups can form a hierarchy, in which a parent group 514 can have several child groups 502, 504, 506, 508, 510, 512. Higher-level child groups 506, 512 can also be parent groups of lower-level child groups 502, 504, 508, 510. Each group level can have a dedicated maintenance contact. The maintenance contact can be responsible for at least one of the following: remote or on-site maintenance tasks. Therefore, maintenance can be considered at several levels, and if necessary, warnings can be gradually upgraded along the group level. For example, if a group does not manage and repair certain faults for some reason, the problem can be upgraded to the parent group. In general, parent groups can be responsible for their child groups.

[0072] In an embodiment, the method may include prioritizing alarms hierarchically. Alarms and the urgency of the alarms may be determined for each group. At a parent group level, several parent groups may be calculated together to view the situation across several groups. Additionally, multiple groups may be grouped together at several levels to create a drill-down possibility of where the failure is located. This may further enable escalation logic regarding the levels of the group hierarchy and from one level to another.

[0073] Each subgroup 502, 504, 506, 508, 510, 512 may have a certain number of faults. In addition, a sum of the fault priority index points of the faults may be determined for the group. The faults and fault priority index of the parent group 514 are determined based on the sum of the values ​​of all subgroups 502, 504, 506, 508, 510, 512. If a lower level group 502, 504, 506, 508, 510, 512 fails to manage and repair one or more faults, the problem can be escalated to the parent group 514. However, the problem should not be escalated immediately or too easily. One goal is to escalate the problem only when one or more charging stations may have a serious fault.

[0074] In one embodiment, the method may include determining an escalation index. The escalation index is a number that indicates how many serious faults are present in a group of charging stations before an alert about the fault is escalated to a higher level group. The escalation index may be more than just a simple sum or average of the faults.

[0075] For example, if a group has 10 charging stations and one of them has a serious fault, the average number of faults is high, i.e., 10% of the charging stations have faults. In this case, no upgrade needs to be generated because only one charging station has a fault.

[0076] To make the upgrade logic more appropriate, two indicators are combined for the upgrade index, the sum of charging stations with faults in each group and the fault priority index of these faults. Thus, in the case where many charging stations have low priority faults, an upgrade may not be needed. On the other hand, in the case where many charging stations have high priority faults, the upgrade may be triggered.

[0077] In one embodiment, the upgrade index may be determined based on the number of faulty charging stations having a fault priority index value equal to or higher than 25 points, the sum of the fault priority index points equal to or higher than 25 points, and the number of healthy charging stations having a fault priority index value lower than 25 points. The upgrade index may be determined as follows:

[0078] Upgrade index = (number of faulty charging stations * sum of fault priority index points) / (number of healthy stations).

[0079] For example, there may be ten charging stations in the first group, which have a total of 920 fault priority index points (where 1000 points is the maximum). In addition, the first group may have 500 healthy charging stations. Therefore, the upgrade index becomes (10*920) / 500=18.4.

[0080] As another example, in the second group there may be 20 charging stations with a total of 500 fault priority index points (with a maximum of 2000 points), and 30 healthy charging stations. The upgrade index would now be (20*500) / 30=333. Thus, based on the upgrade index, the second group is much worse than the first group, even though the total number of fault priority index points is higher for the first group.

[0081] In one embodiment, the method may include determining an upgrade index limit for each child group before management of the fault is upgraded to the corresponding parent group. For example, for group 1 506, the upgrade index limit may be 150, for group 2 512, the upgrade index limit may be 100, and for group 1.1 504, the upgrade index limit may be 130. Therefore, when the upgrade index of the lower level (group 1.1504 and 1.2 502) is equal to or greater than 150, group 1 506 may receive an upgrade warning. Any upgrade index limit may be updated, for example, when the number of charging stations in the group changes. When the upgrade index limit is exceeded, the method may include sending a report to a maintenance person. For example, each group may have a primary maintenance contact. For example, a report may be sent via email or on a web page. The report may include an overview of which organization has a problem and where to dig deeper into the details.

[0082] In one embodiment, the report may include data on the total fault priority index for the group, the number of unhealthy charging stations, the number of healthy charging stations, and the sum of one or more fault indicators for the group. Maintenance personnel can search for more details, such as a list of faulty charging stations in the group and their respective fault priority indicators. In addition, the report may enable maintenance personnel to investigate details about individual charging stations, such as each fault that occurred, the priority of the fault, the fault indicator, the recommended action, and the action performed. Therefore, the management of emergency faults can be optimized.

[0083] Figure 6 An example of an apparatus 600 configured to implement one or more example embodiments is illustrated.

[0084] The apparatus 600 may include at least one processor 602. The at least one processor 602 may include, for example, one or more of various processing devices, such as a coprocessor, a microprocessor, a controller, a digital signal processor (DSP), a processing circuit with or without an accompanying DSP, or various other processing devices, including integrated circuits, such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), microcontroller units (MCUs), hardware accelerators, or dedicated computer chips, etc.

[0085] The apparatus 600 may also include at least one memory 604. The memory may be configured to store, for example, computer program code 606, such as operating system software and application software. The memory 604 may include one or more volatile memory devices, one or more non-volatile memory devices, and / or a combination thereof. For example, the memory may be implemented as a magnetic storage device (such as a hard drive, a magnetic tape, etc.), an optical magnetic storage device, or a semiconductor memory (such as a mask ROM, a PROM (programmable ROM), an EPROM (erasable PROM), a flash ROM, a RAM (random access memory), etc.).

[0086] The device 600 may further include a communication interface 608, which is configured to enable the device 200 to transmit information to other devices (e.g., a charging station) and / or receive information from other devices. The communication interface may be configured to provide at least one radio connection, such as 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, such as a wireless local area network (WLAN) connection, such as a WLAN connection standardized by the IEEE 802.11 series or the Wi-Fi Alliance; a short-range wireless network connection, such as Bluetooth, NFC (near field communication) or RFID connection; a wired connection, such as a local area network (LAN) connection, a universal serial bus (USB) connection or an optical network connection, etc.; or a wired Internet connection. The communication interface 208 may include or be configured to be coupled to at least one antenna to send and / or receive radio frequency signals. One or more of the various types of connections may also be implemented as a separate communication interface, which may be coupled or configured to be coupled to multiple antennas. The device 600 may also include a user interface 610, which includes an input device and / or an output device.

[0087] When the device 600 is configured to implement some functions, a certain component and / or multiple components (such as at least one processor 602 and / or memory 604) of the device 600 can be configured to implement the function. In addition, when at least one processor 602 is configured to implement some functions, the function can be implemented using, for example, the program code 606 included in the memory 604.

[0088] The functions 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 device includes a processor or processor circuit, such as, for example, a microcontroller, which is configured by program code to perform the described operations and embodiments of the functions when executed. Alternatively or additionally, the functions described herein may be performed at least in part by one or more hardware logic components. For example, but not limited to, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chip (SOCs), complex programmable logic devices (CPLDs), and graphics processing units (GPUs).

[0089] The device 600 includes a module for performing at least one method described herein. In one example, the module includes at least one processor 602, at least one memory 604 including program code 606, and the program code is configured to cause the device 600 to perform the method when executed by the at least one processor 602.

[0090] The apparatus 600 may include, for example, a computing device, such as, for example, a server device, a client device, a mobile phone, a tablet computer, or a laptop computer. Although the apparatus 600 is illustrated as a single device, it should be understood that the functionality of the apparatus 600 may be distributed to multiple devices whenever applicable. In one example, the apparatus 600 may include a CSMS server device.

[0091] It is obvious to a person skilled in the art that the basic idea of ​​the invention can be implemented in various ways as technology advances. Therefore, the invention and its embodiments are not limited to the above examples, but they can vary within the scope of the claims.

[0092] Further features of the method result directly from the functionality and parameters of the apparatus described in the appended claims and throughout the specification and are therefore not repeated here. Note that one or more operations of the method may be performed in a different order.

[0093] A device may be configured to perform or cause the performance of any aspect of the method(s) described herein. In addition, a computer program may include instructions for causing a device to perform any aspect of the method(s) described herein when executed. In addition, a device may include a module for performing any aspect of the method(s) described herein. According to an example embodiment, the module includes at least one processor and a memory including program code, the at least one memory and the program code being configured to cause the performance of any aspect of the method(s) when executed by the at least one processor.

[0094] Any range or device value given herein may be expanded or altered without losing the effect sought. Furthermore, any embodiment may be combined with another embodiment unless expressly prohibited.

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

[0096] It should 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 embodiments that solve any or all of the problems described, or those embodiments that have any or all of the benefits and advantages described. It will also be understood that reference to "an" item may refer to one or more of these items.

[0097] The operations of the methods described herein may be performed in any appropriate order, or simultaneously where appropriate. In addition, individual blocks may be deleted from any method without departing from the scope of the subject matter described herein. Aspects of any of the above-described embodiments may be combined with aspects of any other embodiment described to form additional embodiments without losing the effects sought.

[0098] The term "comprising" is used herein to mean including the identified methods, blocks or elements, but such blocks or elements do not include an exclusive list and the method or apparatus may contain additional blocks or elements.

[0099] As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) a hardware-only circuit implementation (such as an implementation in analog and / or digital circuitry only) and (b) a combination of hardware circuitry and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) and software / firmware, and (ii) any portion of a hardware processor(s) with software (including digital signal processor(s)), software and memory(s) that work together to enable a device 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) to operate, but where software is not required to operate, the software may be absent. This definition of circuitry applies to all uses of the term in this application (including in any claims).

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

[0101] It should be understood that the above description is given as an example only, and various modifications may be made by those skilled in the art. The above description, examples and data provide a complete description of the structure and use of the exemplary embodiments. Although various embodiments are described above with a certain degree of particularity or with reference to one or more separate embodiments, those skilled in the art may make many changes to the disclosed embodiments without departing from the scope of this specification.

Claims

1. A method (200) for managing failures of an electric vehicle charging station, comprising: detecting a trigger for calculating a fault priority indicator for at least one electric vehicle charging station; determining more than one fault indicator, the fault indicator comprising at least one of: a duration of an offline state, a frequency of the offline state, a duration of faults, a frequency of the faults, or a number of rejected commands within a predetermined interval at the electric vehicle charging station; calculating the fault priority index by combining the values ​​of the fault indicators; determining a priority level of the fault priority indicator and one or more actions for the priority level based on a plurality of priority levels having different predetermined thresholds for the fault priority indicator; initiating at least one action to manage a fault at the at least one electric vehicle charging station based on the priority level of the fault priority indicator, wherein the at least one action comprises automatically sending one or more commands configured to at least one of: restart or change one or more settings at the electric vehicle charging station; After performing the at least one action, updating the fault priority indicator of the electric vehicle charging station; as well as If the updated fault priority indicator indicates that the fault still exists, another action is initiated according to the priority level of the fault priority indicator.

2. The method (200) of claim 1, wherein the trigger comprises at least one of: an indication that the electric vehicle charging station is offline, a fault status notification from the electric vehicle charging station, a rejection of a command by the electric vehicle charging station, a failure of the electric vehicle charging station to respond to a command, or a return of the electric vehicle charging station to a normal state.

3. The method (200) according to claim 1 or 2, wherein the frequency of the offline state is determined based on a total duration of the offline state of the electric vehicle charging station within the predetermined interval.

4. The method (200) according to claim 1 or 2, wherein: The frequency of the failure of the electric vehicle charging station is determined based on a total duration of the failure of the electric vehicle charging station within the predetermined interval.

5. The method (200) according to claim 1 or 2, wherein the one or more actions include at least one of: providing a list of the electric vehicle charging stations in order of urgency based on the fault priority index, providing recommendations on how to repair the fault, restarting the electric vehicle charging station, performing a firmware update on the electric vehicle charging station, resetting the Internet connection of the electric vehicle charging station, warning of remote maintenance, or warning of on-site maintenance.

6. The method (200) according to claim 1 or 2, further comprising: grouping a plurality of electric vehicle charging stations into a plurality of subgroups; grouping the plurality of subgroups into one or more parent groups; determining the upgrade index of each group by: multiplying the number of faulty electric vehicle charging stations in the group by the sum of the fault priority indexes in the group, and dividing the multiplied value by the number of non-faulty electric vehicle charging stations in the group; and When the escalation indicator exceeds a predetermined limit for the child group, a notification is provided to contacts of the parent group.

7. An apparatus (600) for managing failures of an electric vehicle charging station, the apparatus comprising at least one processor (602); and at least one memory (604) comprising program code (606), the program code being configured to, together with the at least one processor (602), cause the apparatus (600) to at least perform the following operations: detecting a trigger for calculating a fault priority indicator for at least one electric vehicle charging station; determining more than one fault indicator, the fault indicator comprising at least one of: a duration of an offline state, a frequency of the offline state, a duration of the fault, a frequency of the fault, or a number of rejected commands within a predetermined interval at the electric vehicle charging station; calculating the fault priority indicator by combining the values ​​of the more than one fault indicators; determining a priority level of the fault priority indicator and one or more actions for the priority level based on a plurality of priority levels having different predetermined thresholds for the fault priority indicator; initiating at least one action to manage a fault at the at least one electric vehicle charging station based on the priority level of the fault priority indicator, wherein the at least one action comprises automatically sending one or more commands configured to at least one of: restart or change one or more settings at the electric vehicle charging station; After performing the at least one action, updating the fault priority indicator of the electric vehicle charging station; as well as If the updated fault priority indicator indicates that the fault still exists, another action is initiated according to the priority level of the fault priority indicator.

8. The apparatus (600) of claim 7, wherein the trigger comprises at least one of: an indication that the electric vehicle charging station is offline, a fault status notification from the electric vehicle charging station, a rejection of a command by the electric vehicle charging station, a failure of the electric vehicle charging station to respond to a command, or a return of the electric vehicle charging station to a normal state.

9. An apparatus (600) according to claim 7 or 8, wherein the one or more actions include at least one of the following: providing a list of the electric vehicle charging stations in order of urgency based on the fault priority index, providing recommendations on how to repair the fault, restarting the electric vehicle charging station, performing a firmware update on the electric vehicle charging station, resetting the Internet connection of the electric vehicle charging station, warning of remote maintenance, or warning of on-site maintenance.

10. The apparatus (600) according to claim 7 or 8, wherein the at least one memory further comprises program code, the program code being configured to, with the at least one processor, cause the apparatus to: grouping a plurality of electric vehicle charging stations into a plurality of subgroups; grouping the plurality of subgroups into one or more parent groups; determining the upgrade index of each group by multiplying the number of faulty electric vehicle charging stations in the group by the sum of the fault priority indexes in the group, and dividing the multiplied value by the number of non-faulty electric vehicle charging stations in the group; and When the escalation indicator exceeds a predetermined limit for the child group, a notification is provided to contacts of the parent group.

11. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to perform the method (200) according to any one of claims 1 to 6.

Images