WO2021068947A1 - 充电桩故障识别的***和方法 - Google Patents

充电桩故障识别的***和方法 Download PDF

Info

Publication number
WO2021068947A1
WO2021068947A1 PCT/CN2020/120248 CN2020120248W WO2021068947A1 WO 2021068947 A1 WO2021068947 A1 WO 2021068947A1 CN 2020120248 W CN2020120248 W CN 2020120248W WO 2021068947 A1 WO2021068947 A1 WO 2021068947A1
Authority
WO
WIPO (PCT)
Prior art keywords
charging pile
abnormal
charging
order
state data
Prior art date
Application number
PCT/CN2020/120248
Other languages
English (en)
French (fr)
Inventor
徐阳阳
赵叶
梁明
Original Assignee
北京嘀嘀无限科技发展有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN201910958433.0A external-priority patent/CN110646699A/zh
Priority claimed from CN201911408140.1A external-priority patent/CN111038320B/zh
Priority claimed from CN202010167714.7A external-priority patent/CN111815389A/zh
Application filed by 北京嘀嘀无限科技发展有限公司 filed Critical 北京嘀嘀无限科技发展有限公司
Publication of WO2021068947A1 publication Critical patent/WO2021068947A1/zh

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60L—PROPULSION OF ELECTRICALLY-PROPELLED VEHICLES; SUPPLYING ELECTRIC POWER FOR AUXILIARY EQUIPMENT OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRODYNAMIC BRAKE SYSTEMS FOR VEHICLES IN GENERAL; MAGNETIC SUSPENSION OR LEVITATION FOR VEHICLES; MONITORING OPERATING VARIABLES OF ELECTRICALLY-PROPELLED VEHICLES; ELECTRIC SAFETY DEVICES FOR ELECTRICALLY-PROPELLED VEHICLES
    • B60L53/00—Methods of charging batteries, specially adapted for electric vehicles; Charging stations or on-board charging equipment therefor; Exchange of energy storage elements in electric vehicles
    • B60L53/60—Monitoring or controlling charging stations
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01D—MEASURING NOT SPECIALLY ADAPTED FOR A SPECIFIC VARIABLE; ARRANGEMENTS FOR MEASURING TWO OR MORE VARIABLES NOT COVERED IN A SINGLE OTHER SUBCLASS; TARIFF METERING APPARATUS; MEASURING OR TESTING NOT OTHERWISE PROVIDED FOR
    • G01D21/00—Measuring or testing not otherwise provided for
    • G01D21/02—Measuring two or more variables by means not covered by a single other subclass
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/06—Energy or water supply
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/70—Energy storage systems for electromobility, e.g. batteries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/7072—Electromobility specific charging systems or methods for batteries, ultracapacitors, supercapacitors or double-layer capacitors
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/12—Electric charging stations

Definitions

  • the present application relates to a system and method for identifying the fault of a charging pile, and in particular to a system and method for determining the cause of a charging pile fault and monitoring the charging pile.
  • charging piles As an indispensable charging device for new energy vehicles, charging piles have a high utilization rate in daily life. Charging piles that are safe, durable and easy to operate play a key role in the charging of new energy vehicles. When the user uses the charging pile, the charging pile is usually in an unattended self-service state, and its working status cannot be guaranteed in a timely and effective manner. The user often encounters abnormal charging problems during the charging process, such as user violations. Operation, charging pile failure, charging vehicle failure, etc.
  • One aspect of the present application relates to a method for identifying a fault of a charging pile.
  • the method includes: in response to obtaining a charging request, generating an order for the charging request; obtaining charging state data during the current charging operation of the vehicle; determining whether the charging state data includes abnormal state data; responding to the determination If the charging state data includes the abnormal state data, it is determined that the order is an abnormal order, and an identifier corresponding to the abnormal state data is generated for the abnormal order; and the abnormal order is sent to the The server connected to the charging pile.
  • the charging state data includes state data of operable parts of the charging pile.
  • determining that the order is an abnormal order, and generating an identifier corresponding to the abnormal state data for the abnormal order includes: responding to determining the charging If the state data of the operable part of the pile is an abnormal state, a first identifier is generated for the abnormal order.
  • the charging state data includes interaction data between a charging post and the vehicle.
  • determining that the order is an abnormal order, and generating an identifier corresponding to the abnormal state data for the abnormal order includes: in response to determining the interaction If the data is in an abnormal state, a second identifier is generated for the abnormal order.
  • generating an identifier corresponding to the abnormal state data for the abnormal order includes: obtaining a mapping relationship between the abnormal state data and the identifier; and determining the abnormal state data according to the mapping relationship and the abnormal state data.
  • the identifier of the abnormal order includes: obtaining a mapping relationship between the abnormal state data and the identifier; and determining the abnormal state data according to the mapping relationship and the abnormal state data. The identifier of the abnormal order.
  • the second aspect of the present application relates to a method for fault identification and monitoring of charging piles.
  • the method includes: acquiring information of an abnormal order, the abnormal order reflecting the presence of abnormal state data during the charging operation of the charging pile, the information of the abnormal order including an identifier corresponding to the abnormal state data; and according to The identifier determines the reason for the abnormality of the abnormal order.
  • the abnormal cause includes at least one of charging pile failure, vehicle failure, and abnormal operation.
  • determining the reason for the abnormality of the abnormal order according to the identifier includes: obtaining charging pile information corresponding to the abnormal order; obtaining historical abnormalities corresponding to the charging pile information in a historical time period Order information; acquiring the historical identifier in the information of the historical abnormal order; and determining the abnormal reason of the abnormal order according to the proportion of the identifier in the historical identifier.
  • the identifier is a first identifier
  • the first identifier indicates that the state data of the operable component of the charging pile is an abnormal state
  • the abnormal order is determined according to the identifier.
  • the reason for the abnormality includes: determining whether the proportion of the first identifier in the historical identifier is greater than a threshold.
  • the method further includes: in response to determining that the proportion of the first identifier in the historical identifier is greater than the threshold, determining that the cause of the abnormality is a charging pile failure.
  • the method further includes: in response to determining that the proportion of the first identifier in the historical identifier is less than the threshold, determining that the cause of the abnormality is an abnormal operation.
  • the identifier is a second identifier
  • the second identifier indicates that the interaction data between the charging post and the vehicle being charged is in an abnormal state
  • the identifier is used to determine the
  • the abnormal reason for the abnormal order includes: determining whether the proportion of the second identifier in the historical identifier is greater than a threshold.
  • the method further includes: in response to determining that the proportion of the second identifier in the historical identifier is greater than the threshold, determining that the cause of the abnormality is a charging pile failure.
  • the method further includes: in response to determining that the proportion of the second identifier in the historical identifier is less than the threshold, determining that the cause of the abnormality is a vehicle failure.
  • the method further includes: generating a mapping relationship between abnormal state data and an identifier; and sending the mapping relationship to the charging pile.
  • the method further includes: generating a mapping relationship between the reason for the abnormality and the processing personnel; and sending the reason for the abnormality to the terminal of the corresponding processing personnel.
  • the abnormal cause of the abnormal order is a failure of the charging pile
  • the method further includes: determining that the charging pile corresponding to the abnormal order is an abnormal charging pile; and performing a monitoring operation on the abnormal charging pile.
  • determining that the charging pile corresponding to the abnormal order is an abnormal charging pile includes: if multiple consecutive charging orders related to the charging pile are all abnormally stopped, and the reason for the abnormal stop is the charging pile If it fails, it is determined that the charging pile is an abnormal charging pile.
  • the monitoring operation includes an isolation operation
  • the isolation operation includes: in response to obtaining a charging request from a client, if the charging pile requested by the charging request is the abnormal charging pile, sending a request to the The client returns abnormal information about the abnormal charging pile, and/or provides the client with guidance information about other normal charging piles other than the abnormal charging pile.
  • the monitoring operation includes a repair operation
  • the repair operation includes: determining whether the version of the abnormal charging pile is the latest available version.
  • the repair operation further includes: in response to determining that the version of the abnormal charging pile is the latest available version, sending a restart instruction to the abnormal charging pile.
  • the repair operation further includes: in response to determining that the version of the abnormal charging pile is not the latest available version, sending an upgrade instruction to the abnormal charging pile.
  • the corresponding processing personnel sends a maintenance work order for the abnormal charging pile.
  • the abnormal charging pile is set as a normal charging pile.
  • the third aspect of the present application relates to a method for identifying faults of charging piles.
  • the method includes: acquiring the time point at which the server receives the current communication data, the communication data being sent by the charging pile; taking the time point as a starting point, determining whether the server receives a new communication within a preset first time threshold Data; and in response to determining that the server does not receive new communication data within a preset first time threshold, it is determined that the charging pile has an offline failure point.
  • the method further includes: determining whether the charging pile has continuous offline fault points and the number of the continuous offline fault points exceeds a fault point threshold; and in response to determining that the charging pile has continuous If the number of offline fault points exceeds the fault point threshold, it is determined that the charging pile has a fault.
  • the method further includes: using the time point as a starting point, determining whether the server has not received new communication data within a preset second time threshold, wherein the second time threshold is greater than the The first time threshold; and in response to determining that the server does not receive new communication data within the preset second time threshold, it is determined that the charging pile is faulty.
  • the communication data includes a heartbeat signal or charging status data.
  • the charging status data includes an abnormal order signal
  • the method further includes: obtaining the number of historical abnormal orders and the total number of historical orders of the charging pile; and determining that the number of historical abnormal orders of the charging pile accounts for historical abnormal orders. Whether the proportion of the total number of orders exceeds the proportion threshold; and in response to determining that the proportion of the number of historical abnormal orders of the charging pile to the total number of historical orders exceeds the proportion threshold, it is determined that the charging pile is faulty.
  • the charging state data includes state data of the charging pile
  • the method further includes: in response to determining that the server receives new communication data within a preset first time threshold, acquiring the charging pile Determine whether the state data of the charging pile is within a preset range; and in response to determining that the state data of the charging pile is not within the preset range, it is determined that the charging pile is faulty.
  • the status data of the charging pile includes the temperature, current value, voltage value of the operable parts of the charging pile, the real-time output power of the charging pile, the accumulated charging time of the charging pile, and the accumulated charging amount of the charging pile. At least one item of.
  • the communication data includes fault information
  • the method further includes: determining that the charging pile has a fault.
  • the method further includes: in response to determining that the charging pile is faulty, acquiring the device attribute of the charging pile and the first terminal attribute corresponding to the device attribute; and according to the first terminal The attribute sends fault reminder information to the first terminal, where the fault reminder information includes the device attribute of the charging pile.
  • the method further includes: obtaining the proportion of charging piles determined to be faulty in the charging station to the total number of charging piles; determining whether the proportion exceeds a threshold; in response to determining that the proportion exceeds the threshold, Acquiring the site attribute of the charging station and the second terminal attribute corresponding to the site attribute; and sending alarm information to the second terminal according to the second terminal attribute, the alarm information including the site attribute of the charging station.
  • the fourth aspect of the application relates to a method for identifying and monitoring faults of charging piles.
  • the method includes: acquiring the information of the charging order and analyzing the information of the charging order; if the charging order is abnormally stopped, and the reason for the abnormal stop is caused by the abnormal charging pile, determining that the charging pile is abnormal charging Pile; and monitoring the charging pile.
  • determining that the charging pile is an abnormal charging pile includes: if a plurality of continuous charging orders related to the charging pile are all abnormally stopped, and the reason for the abnormal stop is all charging pile failure, then determining The charging pile is an abnormal charging pile.
  • the monitoring operation includes an isolation operation
  • the isolation operation includes: in response to obtaining a charging request from a client, if the charging pile requested by the charging request is the abnormal charging pile, sending a request to the The client returns abnormal information about the abnormal charging pile, and/or provides the client with guidance information about other normal charging piles other than the abnormal charging pile.
  • the monitoring operation includes a repair operation
  • the repair operation includes: determining whether the version of the abnormal charging pile is the latest available version.
  • the repair operation further includes: in response to determining that the version of the abnormal charging pile is the latest available version, sending a restart instruction to the abnormal charging pile.
  • the repair operation further includes: in response to determining that the version of the abnormal charging pile is not the latest available version, sending an upgrade instruction to the abnormal charging pile.
  • the corresponding processing personnel sends a maintenance work order for the abnormal charging pile.
  • the abnormal charging pile is set as a normal charging pile.
  • the fifth aspect of the present application relates to a system for identifying faults of charging piles.
  • the system includes: one or more storage devices that store a set of instructions for identifying faults in the charging pile; and one or more processors that communicate with the one or more storage devices, wherein, when the set of instructions is executed,
  • the one or more processors are configured to: in response to obtaining a charging request, generate an order for the charging request; obtain charging state data during the current charging operation of the vehicle; determine whether the charging state data includes abnormal state data In response to determining that the charging state data includes the abnormal state data, determining that the order is an abnormal order, and generating an identifier corresponding to the abnormal state data for the abnormal order; and sending the abnormal order To the server connected to the charging pile.
  • the sixth aspect of the present application relates to a system for identifying and monitoring faults of charging piles.
  • the system includes: one or more storage devices that store a set of instructions for charging pile fault identification and monitoring; and one or more processors that communicate with the one or more storage devices, wherein, when the set of instructions is executed When instructed, the one or more processors are used to: obtain information about an abnormal order, the abnormal order reflects the presence of abnormal state data during the charging operation of the charging pile, and the information of the abnormal order includes information related to the abnormal state data. Corresponding identifier; and, according to the identifier, determine the reason for the abnormality of the abnormal order.
  • the seventh aspect of the present application relates to a system for identifying faults of charging piles.
  • the system includes: one or more storage devices that store a set of instructions for charging pile fault identification and monitoring; and one or more processors in communication with the one or more storage devices, wherein, when the set of instructions is executed When instructing, the one or more processors are used to: obtain the time point when the server receives the current communication data, the communication data is sent by the charging pile; taking the time point as the starting point, determine that the time is within the preset first time threshold Whether the server receives new communication data; and in response to determining that the server does not receive new communication data within a preset first time threshold, it is determined that the charging pile has an offline fault point.
  • the eighth aspect of the present application relates to a system for identifying and monitoring faults of charging piles.
  • the system includes: one or more storage devices that store a set of instructions for charging pile fault identification and monitoring; and one or more processors in communication with the one or more storage devices, wherein, when the set of instructions is executed When instructing, the one or more processors are used to: obtain the information of the charging order and analyze the information of the charging order; if the charging order is abnormally stopped and the reason for the abnormal stop is caused by the abnormal charging pile, it is determined The charging pile is an abnormal charging pile; and a monitoring operation is performed on the charging pile.
  • the ninth aspect of the present application relates to a computer-readable storage medium, the storage medium stores computer instructions, and when the computer instructions are executed by a processor, a method for recognizing a fault of a charging pile is implemented, the method comprising: responding To obtain a charging request, generate an order for the charging request; obtain charging state data during the current charging operation of the vehicle; determine whether the charging state data includes abnormal state data; in response to determining that the charging state data is If the abnormal state data is included, it is determined that the order is an abnormal order, and an identifier corresponding to the abnormal state data is generated for the abnormal order; and the abnormal order is sent to a server connected to the charging pile.
  • the tenth aspect of the present application relates to a computer-readable storage medium, the storage medium stores computer instructions, and when the computer instructions are executed by a processor, a method for identifying and monitoring faults of a charging pile is realized, the method comprising : Acquire information about an abnormal order, the abnormal order reflects the presence of abnormal state data during the charging operation of the charging pile, the information of the abnormal order includes an identifier corresponding to the abnormal state data; and according to the identifier To determine the reason for the abnormal order.
  • the eleventh aspect of the present application relates to a computer-readable storage medium that stores computer instructions, and when the computer instructions are executed by a processor, a method for recognizing a fault in a charging pile is implemented, the method comprising: Acquiring the time point at which the server receives the current communication data, the communication data being sent by the charging pile; taking the time point as a starting point, determining whether the server receives new communication data within a preset first time threshold; and responding to It is determined that the server does not receive new communication data within the preset first time threshold, and then it is determined that the charging pile has an offline fault point.
  • the twelfth aspect of the present application relates to a computer-readable storage medium, the storage medium stores computer instructions, and when the computer instructions are executed by a processor, a method for recognizing and monitoring faults of a charging pile is implemented. Including: obtaining the information of the charging order, and analyzing the information of the charging order; if the charging order is abnormally stopped and the reason for the abnormal stop is caused by the abnormal charging pile, determining that the charging pile is an abnormal charging pile; and Perform monitoring operations on the charging pile.
  • Fig. 1 is a schematic diagram of an exemplary charging monitoring system according to some embodiments of the present application.
  • Fig. 2 is a schematic diagram of exemplary hardware and/or software components of an exemplary mobile device on which a client terminal can be implemented according to some embodiments of the present application;
  • FIG. 3 is a schematic diagram of exemplary hardware and software components of an exemplary computing device according to some implementations of the present application.
  • Fig. 4 is an exemplary module diagram of a charging pile according to some embodiments of the present application.
  • Fig. 5 is an exemplary block diagram of a processing device according to some embodiments of the present application.
  • FIG. 6 is a flowchart of an exemplary process 600 for identifying a fault of a charging pile according to some embodiments of the present application
  • FIG. 7 is a flowchart of an exemplary process 700 for determining the abnormal cause of an abnormal order according to some embodiments of the present application.
  • FIG. 8 is a flowchart of an exemplary process 800 for monitoring charging piles according to some embodiments of the present application.
  • FIG. 9 is a flowchart of an exemplary process 900 for monitoring charging piles according to some embodiments of the present application.
  • FIG. 10 is a flowchart of an exemplary process 1000 of a charging pile monitoring method according to some embodiments of the present application.
  • FIG. 11 is a flowchart of an exemplary process 1100 for identifying a fault of a charging pile according to some embodiments of the present application.
  • FIG. 12 is a flowchart of an exemplary process 1200 for identifying a fault of a charging pile according to some embodiments of the present application
  • FIG. 13 is a flowchart of an exemplary process 1300 for identifying a fault of a charging pile according to some embodiments of the present application
  • Fig. 14 is a schematic diagram of an exemplary charging monitoring system according to some embodiments of the present application.
  • Fig. 15A is an exemplary schematic diagram of a data transmission process between a charging pile and a platform server according to some embodiments of the present application;
  • FIG. 15B is an exemplary schematic diagram of the bill transmission process between the charging pile and the platform server according to some embodiments of the present application.
  • Fig. 15C is an exemplary schematic diagram of a signal transmission process between a charging pile and a platform server according to some embodiments of the present application.
  • a flowchart is used in this application to illustrate the operations performed by the system according to some embodiments of the application. It should be understood that the operations in the flowchart may be performed out of order. Instead, the various steps can be processed in reverse order or simultaneously. At the same time, you can also add one or more other operations to these flowcharts, or delete a step or several steps from these flowcharts.
  • service request means a request that can be initiated by a user (eg, passenger, requester, operator, service requester, customer, driver).
  • the service request may involve the use of a charging post to charge an electric vehicle.
  • the system can find applications in many fields, such as taxi transportation services, driving applications, map applications or navigation applications.
  • the occurrence of abnormal orders may be caused by any participant. For example, if the user fails to connect the charging gun after starting charging or forcibly unplugging the charging gun during the charging process, the order is abnormal; another example is that the vehicle battery management system does not respond in time when the charging pile interacts with the vehicle during the charging process. Order abnormalities caused by forcibly ending orders; another example is an order abnormality caused by a malfunction of the charging pile itself, such as a network communication failure between the charging pile and the server or a loose connection device of the charging gun.
  • the charging pile monitoring alarm method is mainly the communication between the charging pile and the platform, allowing the charging pile to actively report the fault and diagnose, but if the charging pile itself is abnormal and does not actively upload fault abnormal information, the platform will not be able to sense in time To failure. At the same time, even if the charging pile is normal at the time of uploading information, it cannot be completely guaranteed that the pile will have no abnormal faults during charging.
  • Existing methods for detecting abnormalities of charging piles are often manually discovered, which means that only after the user feedbacks the abnormality of the equipment, the relevant maintenance personnel will rush to the site to perform maintenance operations. From failure to repair, there is a long delay. And the failure of some charging piles may be "hidden failure", for example, the connection of the charging gun is loose, which often results in abnormal orders during the charging process. This type of problem is often not intuitively observed through surface phenomena, and it is relatively difficult to find.
  • some embodiments of the present application provide systems and methods for automatic fault identification and monitoring of charging piles.
  • the system and method can be applied at the end of a charging pile.
  • the charging pile can respond to charging requests and generate orders.
  • the charging post can obtain charging state data during the charging operation of the vehicle, and determine whether the charging state data includes abnormal state data.
  • the charging pile may determine an abnormal order based on the abnormal state data, and generate an identifier corresponding to the abnormal state data for the abnormal order.
  • the charging pile may send the abnormal order to a server connected to the charging pile.
  • the charging pile can collect charging status data in real time during the charging process of the vehicle.
  • the cause of the abnormal charging order can be determined. For order abnormalities caused by different reasons, different identifications can be configured. symbol. Therefore, when the server receives the abnormal order information, it can determine the reason for the abnormal order according to the identifier.
  • the system and method can be applied to a server connected to a charging pile (for example, a charging pile operator platform server).
  • the server can obtain the information of the abnormal order, and determine the reason for the abnormal order according to the identifier in the abnormal order information.
  • the server can obtain abnormal information from the order information instead of obtaining abnormal information from the device, and can more accurately determine the actual cause of the abnormal order, thereby improving the efficiency of subsequent troubleshooting.
  • the system and method can be applied to a server connected to a charging pile (for example, a charging pile operator platform server).
  • the server can obtain the time point when the server receives the current communication data.
  • the server may use the time point as a starting point to determine whether the server receives new communication data within a preset first time threshold.
  • the server may determine that the charging pile has an offline failure point.
  • it is possible to automatically identify whether the charging pile has an offline fault point, which not only can detect and prevent the offline fault of the charging pile in time, but also improve the comprehensiveness and accuracy of the charging pile fault identification.
  • Fig. 1 is a schematic diagram of an exemplary charging monitoring system according to some embodiments of the present application.
  • the charging monitoring system 100 (referred to as the system 100 for short) can be applied to an online-to-offline service platform, such as a transportation service platform.
  • Exemplary transportation services may include taxi call service, agent driving service, express service, car sharing service, bus service, driver rental service, shuttle service, and the like.
  • the system 100 may include a server 110, a network 120, one or more client terminals 130, one or more electric vehicles 140, a storage device 150, and a charging station 170 including one or more charging piles 160. It should be noted that the system 100 is only an example and is not limiting.
  • the server 110 may be a single server or a server group.
  • the server group may be centralized or distributed (for example, the server 110 may be a distributed system).
  • the server 110 may be local or remote.
  • the server 110 may access information and/or data stored in the client terminal 130 and/or the storage device 150 via the network 120.
  • the server 110 may be directly connected to the client terminal 130, the storage device 150 and/or the charging pile 160 to access the stored information and/or data.
  • the server 110 may be implemented on a cloud platform.
  • the cloud platform may include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-layer cloud, etc., or any combination thereof.
  • the server 110 may be executed on the computing device 300 including one or more components shown in FIG. 3 in the present application.
  • the server 110 may be a charging pile operator service platform.
  • the server 110 may include one or more processing devices 112.
  • the processing device 112 may process information and/or data related to charging requests, charging pile fault identification, and charging pile monitoring to perform one or more functions described in this application. For example, the processing device 112 may obtain information about abnormal orders. The processing device 112 may obtain the identifier corresponding to the abnormal state data in the abnormal order. The processing device 112 may determine the reason for the abnormality of the abnormal order based on the identifier. For another example, the processing device 112 may perform a monitoring operation on the abnormal charging pile. For another example, the processing device 112 may obtain the time point of the current communication data, and the communication data is sent by the charging pile 160.
  • the processing device 112 may use the time point of the current communication data as a starting point to determine whether new communication data is received within a preset first time threshold.
  • the processing device 112 may determine that there is an offline fault point in the charging pile in response to determining that no new communication data is received within the preset first time threshold.
  • the processing device 112 may include one or more processing engines (for example, a single-chip processing engine or a multi-chip processing engine).
  • the processing device 112 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), an application specific instruction processor (ASIP), an image processor (GPU), a physical processor (PPU), a digital signal processor ( DSP), Field Programmable Gate Array (FPGA), Programmable Logic Circuit (PLD), Controller, Microcontroller Unit, Reduced Instruction Set Computer (RISC), Microprocessor, etc. or any combination thereof.
  • the network 120 may facilitate the exchange of information and/or data.
  • one or more components in the system 100 may send information and/data to other components in the system 100 through the network 120.
  • the server 110 may obtain a service request (for example, a charging request) from the client terminal 130 or the charging pile 160 via the network 120.
  • the charging pile 160 may send charging order information or charging status data to the server 110 via the network 120.
  • the network 120 may be any type of wired or wireless network, etc., or any combination thereof.
  • the network 120 may include a cable network, a wired network, an optical fiber network, a telecommunications network, an internal network, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), and a metropolitan area network (MAN) , Public Switched Telephone Network (PSTN), Bluetooth network, ZigBee network, Near Field Communication (NFC) network, etc. or any combination thereof.
  • the network 120 may include one or more network access points.
  • the network 120 may include wired or wireless network access points, such as base stations and/or Internet exchange points 120-1, 120-2, ..., which may be connected to the network through one or more components of the system 100 120 to exchange data and/or information.
  • the client terminal 130 may include a mobile device 130-1, a tablet computer 130-2, a laptop computer 130-3, a motor vehicle built-in device 130-4, etc., or any combination thereof.
  • the client terminal 130 may facilitate communication and/or interaction between the processing device 112 and users associated with the client terminal 130. For example, the client terminal 130 may generate a charging request based on the user's input via the user interface.
  • the processing device 112 may receive a charging request from the client terminal 130.
  • the processing device 112 may send information related to one or more charging stations and/or charging piles to the client terminal 130 for display to the user.
  • the mobile device 130-1 may include a smart home device, a wearable device, a smart mobile device, a virtual reality device, an augmented reality device, etc., or any combination thereof.
  • the smart home equipment may include smart lighting equipment, smart electrical appliance control devices, smart monitoring equipment, smart TVs, smart cameras, walkie-talkies, etc., or any combination thereof.
  • the wearable device may include a smart bracelet, smart footwear, smart glasses, smart helmets, smart watches, smart clothing, smart backpacks, smart accessories, etc., or any combination thereof.
  • the smart mobile device may include a smart phone, a personal digital assistant (PDA), a gaming device, a navigation device, a point of sale (POS), etc., or any combination thereof.
  • the virtual reality device and/or the augmented reality device may include a virtual reality helmet, virtual reality glasses, virtual reality goggles, augmented reality helmets, augmented reality glasses, augmented reality goggles, etc., or any combination thereof.
  • the virtual reality device and/or the augmented reality device may include Google Glass, Oculus Rift, HoloLens, GearVR, or the like.
  • the in-vehicle device 130-4 may include a vehicle-mounted computer or a vehicle-mounted TV.
  • the client terminal 130 may be a device with positioning technology for locating the location of the service requester and/or the client terminal 130.
  • the one or more electric vehicles 140 may include one or more electric vehicles (for example, electric vehicles 140-1, electric vehicles 140-2, etc.), one or more electric motorcycles 140-3, one or more electric bicycles 140-4, etc., Or a combination.
  • the electric vehicle 140 may include an identification for distinguishing from other electric vehicles.
  • the identification of the electric vehicle 140 may include vehicle information, such as vehicle type, vehicle brand, vehicle license plate number, vehicle number, etc., or a combination thereof.
  • the storage device 150 may store data and/or instructions. In some embodiments, the storage device 150 may store data acquired from the client terminal 130. For example, the storage device 150 may store a request for charging the electric vehicle 140 from the client terminal 130. For another example, the storage device 150 may store information related to the electric vehicle 140. For another example, the storage device 150 may store information related to the charging pile 160. For another example, the storage device 150 may store information related to the charging process (for example, charging state data). In some embodiments, the storage device 150 may store data and/or instructions used by the server 110 to execute or use to complete the exemplary methods described in this application. In some embodiments, the storage device 150 may include mass memory, removable memory, volatile read-write memory, read-only memory (ROM), etc., or any combination thereof.
  • Exemplary mass storage devices may include magnetic disks, optical disks, solid state drives, and the like.
  • Exemplary removable storage may include flash drives, floppy disks, optical disks, memory cards, compact disks, magnetic tapes, and the like.
  • An exemplary volatile read-write memory may include random access memory (RAM).
  • Exemplary RAM may include dynamic random access memory (DRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), static random access memory (SRAM), thyristor random access memory (T-RAM), and zero capacitance Random access memory (Z-RAM), etc.
  • DRAM dynamic random access memory
  • DDRSDRAM double data rate synchronous dynamic random access memory
  • SRAM static random access memory
  • T-RAM thyristor random access memory
  • Z-RAM zero capacitance Random access memory
  • Exemplary read-only memory may include mask-type read-only memory (MROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), CD-ROM and digital versatile disk read-only memory, etc.
  • the storage device 150 may be implemented on a cloud platform.
  • the cloud platform may include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, internal cloud, multi-layer cloud, etc., or any combination thereof.
  • the storage device 150 may be connected to the network 120 to communicate with one or more components in the system 100 (for example, the server 110, the client terminal 130, the charging pile 160, the electric vehicle 140).
  • One or more components in the system 100 can access data and/or instructions stored in the storage device 150 via the network 120.
  • the storage device 150 may be directly connected to or communicate with one or more components in the system 100 (for example, the server 110, the client terminal 130, the charging pile 160, the electric vehicle 140).
  • the storage device 150 may be a part of the server 110, the client terminal 130, the charging pile 160, or the electric vehicle 140.
  • the charging station 170 may include one or more charging posts 160.
  • the charging post 160 is configured to charge an electric vehicle (for example, the electric vehicle 140).
  • the charging post 160 may include a power supply device that provides power, a charging interface connected to an electric vehicle, a memory for storing data generated during the charging process, and a controller (for example, the controller 400 shown in FIG. 4). ), one or more sensors, etc. or any combination thereof.
  • the charging pile 160 may further include one or more operable components, for example, a pile body, a charging gun, a cabinet door, an emergency stop button, etc., or any combination thereof.
  • the controller may include an acquisition module (for example, the acquisition module 410 shown in FIG. 4), a generation module (for example, the generation module 420 shown in FIG. 4), and a determination module (for example, the acquisition module 410 shown in FIG. 4).
  • the determination module 430) and the control module for example, the control module 440 shown in FIG. 4) and so on. More description of the controller can be found elsewhere in this application (for example, Figure 4 and its description).
  • the sensor is used to detect the actual status data of the charging pile.
  • the sensor may include a temperature sensor, a current sensor, a voltage sensor, a pressure sensor, etc., or any combination thereof.
  • the temperature sensor is used to detect the real-time temperature of the components of the charging pile (for example, the pile body).
  • the current sensor is used to detect the real-time current value of the component (for example, the charging gun) flowing through the charging pile.
  • the voltage sensor is used to detect the real-time voltage value of the components of the charging pile (for example, the tip of the charging gun).
  • the pressure sensor is used to detect the pressure value between the components of the charging pile (for example, between the tip of the charging gun and the body of the charging pile).
  • the client terminal 130 may be omitted, and the user may directly initiate a charging request on the charging pile 160.
  • Fig. 2 is a schematic diagram of exemplary hardware and/or software components of an exemplary mobile device on which a client terminal can be implemented according to some embodiments of the present application.
  • the mobile device 200 may include one or more central processing units (CPU) 240, one or more graphics processing units (GPU) 230, a display 220, a memory 260, a communication unit 210, a storage unit 290, and one or more input/output (I /O) Equipment 250.
  • the mobile device 200 may also include, but is not limited to, any other suitable components of a system bus or a controller (not shown in FIG. 2). As shown in FIG.
  • the mobile operating system 270 for example, IOS, Android, Windows Phone, etc.
  • the application program 280 may include a browser or other mobile application programs for receiving and processing charging-related information input by the user in the mobile device 200. The user can obtain one or more charging-related information through the system I/O device 250, and provide the information to the server 110 and/or other modules or units of the system 100.
  • FIG. 3 is a schematic diagram of exemplary hardware and software components of an exemplary computing device shown in accordance with some implementations of the present application.
  • the functions of the server 110, the client terminal 130, or the charging pile 160 can be implemented on the computing device 300.
  • the computing device 300 may be configured to perform one or more functions of the server 110, the client terminal 130, and the charging pile 160 disclosed in this application.
  • the processing device 112 may be implemented on the computing device 300 and configured to perform the functions of the processing device 112 disclosed in this application.
  • the computing device 300 may be a general-purpose computer or a special-purpose computer, both of which may be used to implement the system 100 of the present application.
  • the computing device 300 can be used to implement any component of the system 100 as described in this application.
  • the processing device 112 may be implemented on the computing device 300 through its hardware, software programs, firmware, or a combination thereof.
  • only one computer is shown in the figure, but the computer functions related to the charging service described in this application can be implemented in a distributed manner on multiple similar platforms to distribute the processing load.
  • the computing device 300 may include a communication port 350, which is connected to and/or from the network to implement data communication.
  • the computing device 300 may also include one or more processors 320 in the form of processors for executing program instructions.
  • An exemplary computer platform may include an internal communication bus 310, different types of program memory and data memory (for example, a magnetic disk 370, read only memory (ROM) 330, or random access memory (RAM) 340), processed by a computer, and/or Transmission of various data files.
  • the exemplary computer platform also includes program instructions stored in the ROM 330, RAM 340, and/or other forms of non-transitory storage media to be executed by the processor 320.
  • the method and/or process of the present application can be implemented in the form of program instructions.
  • the computing device 300 may also include an input/output device 360, which may support input/output between the computer and other components.
  • the computing device 300 may also receive programming and data through network communication.
  • the computing device 300 may also include a hard disk controller in communication with a hard disk, a keypad/keyboard controller in communication with a keypad/keyboard, a serial interface controller in communication with a serial interface device, and a parallel interface control in communication with a parallel interface device.
  • a hard disk controller in communication with a hard disk
  • a keypad/keyboard controller in communication with a keypad/keyboard
  • a serial interface controller in communication with a serial interface device
  • a parallel interface control in communication with a parallel interface device.
  • the computing device 300 in this application may include multiple CPUs and/or processors, so the operations and/or methods implemented by one CPU and/or processor described in this application may also be implemented by multiple CPUs and/or processors.
  • the CPUs and/or processors are implemented jointly or independently.
  • the CPU and/or processor of the computing device 300 performs operation A and operation B, it should be understood that operation A and operation B can also be processed by two different CPUs and/or operations in the computing device 300.
  • the processors execute jointly or independently (for example, the first processor executes operation A, the second processor executes operation B, or the first and second processors jointly execute operation A and operation B).
  • Fig. 4 is an exemplary module diagram of a charging pile according to some embodiments of the present application.
  • the charging pile 160 may include a controller 400, and the controller 400 may include an acquisition module 410, a generation module 420, a determination module 430, and a control module 440.
  • the obtaining module 410 can obtain data or information.
  • the acquisition module 410 may acquire data/signals from one or more components of the system 100 (for example, the client terminal 130, the electric vehicle 140, the storage device 150) or an external device (for example, a cloud database).
  • the acquired data/signals may include charging requests, charging status data, etc., or any combination thereof.
  • the acquiring module 410 may acquire the charging state data during the current charging operation of the vehicle by the charging post. More descriptions on obtaining charging state data can be found elsewhere in this application (for example, Figure 6 and related descriptions).
  • the generating module 420 may generate data or information. In some embodiments, the generation module 420 may generate an order based on the charging request. For example, in response to obtaining a charging request, the generating module 420 may generate a charging order for the charging request. More descriptions on generating charging orders can be found elsewhere in this application (for example, Figure 6 and related descriptions).
  • the determination module 430 may determine data or information. In some embodiments, the determination module 430 may determine whether the charging state data includes abnormal state data.
  • the abnormal state data may include abnormal state data of the operable parts of the charging pile, abnormal interaction data between the charging pile and the vehicle, and the like.
  • the abnormal state data of the operable parts of the charging pile may include abnormally pulling out the charging gun, abnormally opening the charging cabinet door, abnormally pressing the emergency stop button, and so on.
  • the abnormal interaction data between the charging pile and the vehicle may include abnormal communication connection between the charging pile and the charged vehicle (for example, connection timeout, connection failure), abnormal current battery data of the vehicle fed back to the charging pile by the charged vehicle, and the like.
  • the determining module 430 may determine that the order is an abnormal order, and generate an identifier corresponding to the abnormal state data for the abnormal order. More descriptions on determining whether abnormal state data is included in the charging state data and generating an identifier corresponding to the abnormal state data on the abnormal order can be found elsewhere in this application (for example, FIG. 6 and related descriptions).
  • the control module 440 may send data or information.
  • the control module 440 may send the abnormal order to the server connected to the charging pile.
  • the control module 440 may send the abnormal order and the identifier to the server 110 connected to the charging pile 160.
  • the generating module 420 and the determining module 430 may be integrated into one module.
  • Fig. 5 is an exemplary block diagram of a processing device according to some embodiments of the present application.
  • the processing device 112 may include an acquisition module 510, a determination module 520, and a control module 530.
  • the obtaining module 510 can obtain data or information.
  • the acquisition module 510 may acquire data/signals from one or more components of the system 100 (for example, the client terminal 130, the electric vehicle 140, the storage device 150, the charging pile 160) or an external device (for example, a cloud database).
  • the obtaining module 510 may obtain information about abnormal orders, which may reflect abnormal state data during the charging operation of the charging pile, and the information of abnormal orders may include an identifier corresponding to the abnormal state data.
  • the acquiring module 510 can acquire information about an order and analyze the information about the order.
  • the acquiring module 510 may acquire the time point when the server receives the current communication data, and the communication data is sent by the charging pile.
  • the obtaining module 510 may obtain the historical abnormal order quantity and the total historical order quantity of the charging pile. For another example, the acquiring module 510 may acquire status data of the charging pile. For another example, the obtaining module 510 may obtain the proportion of the charging piles determined to be faulty in the charging station to the total number of charging piles.
  • the determination module 520 may determine data or information. For example, the determining module 520 may determine the abnormal reason of the abnormal order according to the identifier of the abnormal order. For another example, if the order is an abnormal order, and the abnormal reason of the abnormal order is a charging pile failure, the determining module 520 may determine that the charging pile corresponding to the abnormal order is an abnormal charging pile. For another example, if multiple consecutive orders related to the charging pile are all abnormally stopped, and the reason for the abnormal stop is the failure of the charging pile, the determining module 520 may determine that the charging pile is an abnormal charging pile. For another example, the determining module 520 may use the time point as a starting point to determine whether the server receives new communication data within a preset first time threshold.
  • the determining module 520 may, in response to determining that the server does not receive new communication data within a preset first time threshold, determine that the charging pile has an offline fault point. For another example, the determining module 520 may generate an order abnormality identifier for the abnormal order in response to determining that the server does not receive new communication data within the preset first time threshold and the charging status data includes order abnormality information. For another example, the determining module 520 may determine whether the proportion of the number of historical abnormal orders of the charging pile to the total number of historical orders exceeds the proportion threshold. In response to determining that the ratio of the number of historical abnormal orders of the charging pile to the total number of historical orders exceeds the ratio threshold, the determination module 520 may determine that the charging pile is faulty.
  • the determining module 520 may determine that the charging pile is not faulty. For another example, the determining module 520 may determine whether the status data of the charging pile is within a preset range. In response to determining that the state data of the charging pile is not within the preset range, the determining module 520 may determine that the charging pile has a fault. For another example, the determining module 520 may determine whether the proportion of the charging piles determined to be faulty in the charging station to the total number of charging piles exceeds a threshold. In response to determining that the ratio exceeds the threshold, the determining module 520 may acquire the site attribute of the charging station and the second terminal attribute corresponding to the site attribute.
  • the control module 530 can send data or information.
  • the control module 530 can perform monitoring operations on abnormal charging posts.
  • the control module 530 may perform an isolation operation on the abnormal charging pile.
  • the control module 530 may perform repair operations on the abnormal charging pile.
  • the control module 530 may set the abnormal charging pile as a normal charging pile.
  • the control module 530 may send reminder information to the terminal of the processing personnel.
  • the control module 530 may send a maintenance work order regarding the abnormal charging pile to the terminal of the corresponding processing personnel.
  • control module 530 may send fault reminding information to the first terminal according to the attributes of the first terminal, and the fault reminding information includes the device attributes of the charging pile.
  • control module 530 may send alarm information to the second terminal according to the attributes of the second terminal, where the alarm information includes the site attributes of the charging station.
  • the acquiring module 510 and the determining module 520 may be integrated into one module.
  • FIG. 6 is a flowchart of an exemplary process 600 for identifying a fault of a charging pile according to some embodiments of the present application.
  • the process 600 can be executed by the system 100.
  • one or more operations of the process 600 shown in FIG. 6 may be implemented in the system 100 shown in FIG. 1.
  • the process 600 shown in FIG. 6 may be stored in a storage device in the form of instructions, and called and/or executed by the charging pile.
  • the operation of the flow shown below is for illustrative purposes only.
  • the process 600 may include one or more additional operations not described and/or one or more operations not discussed.
  • the operation sequence of the flow shown in FIG. 6 and described below is not restrictive.
  • an order is generated for the charging request. This step may be performed by the charging pile 160 (for example, the generating module 420).
  • the charging request may be a service demand initiated by the user based on insufficient or lack of power of the electric vehicle.
  • the charging request may include vehicle information related to the electric vehicle to be charged.
  • vehicle information related to the electric vehicle may include the license plate number of the electric vehicle, the model of the electric vehicle, the current power of the electric vehicle, the model of the charger of the electric vehicle, etc., or any combination thereof.
  • a user may initiate a charging request through a client terminal (for example, the client terminal 130), and the charging pile may receive the charging request from the client terminal.
  • the user can initiate a charging request through the user interface (for example, an application) of the client terminal.
  • the user can initiate a charging request by scanning the charging code of the charging pile head by using the client terminal.
  • the user can directly initiate a charging request through the charging pile.
  • the charging pile may include an operation interface, and the user may initiate a charging request through the operation interface of the charging pile.
  • the charging post may generate a charging order based on the charging request.
  • the charging request may be sent to a server (for example, the processing device 112), and the server may send a charging start signal to the charging pile according to the user's charging request, and at the same time allocate a charging order for the current charging operation.
  • Order information can include user information (for example, identity information, user history charging request, user history charging record, user current geographic location), electric vehicle information (for example, vehicle model, license plate number, historical charging record, full charge required Power, current power), charging station information (for example, charging station number, charging status data, charging station charging power, charging station cumulative charging power, charging station historical maintenance records), etc., or any combination thereof.
  • the order information may include information reserved when the user registers (for example, user terminal information, information about charging vehicles) or information obtained in real time (for example, information about charging piles).
  • the charging state data is acquired. This step may be performed by the charging pile 160 (for example, the acquisition module 410).
  • the charging pile may obtain charging state data.
  • the charging status data can include the status data of the charging pile (for example, the status data of the operable parts of the charging pile), the interaction data between the charging pile and the vehicle, the reminder signal sent when the charging is started or ended, the charging process and the charging amount calculation Related signals, billing data sent after charging, etc. or any combination thereof.
  • operable components may refer to components that can be manipulated by humans.
  • the operable components of the charging pile may include a pile body, a charging gun, a charging pile cabinet door, and a charging pile emergency stop button.
  • the state data of the operable parts of the charging pile may include the temperature, current value, voltage value of the operable parts of the charging pile, the real-time output power of the charging pile, the accumulated charging time of the charging pile, and the accumulated charging amount of the charging pile.
  • the interaction data between the charging pile and the vehicle may include the communication connection state between the charging pile and the charged vehicle, the current power data of the vehicle fed back to the charging pile by the charged vehicle, and the like.
  • the charging pile can use sensors, communication modules, etc. installed inside the charging pile to detect charging status data in real time, perform data communication with the charged vehicle, and perform data communication with the server.
  • the sensors of the charging post may include a first temperature sensor, a second temperature sensor, a current sensor, a voltage sensor, a pressure sensor, etc., or any combination thereof.
  • the first temperature sensor may be used to detect the real-time temperature value of the charging pile body as the actual state data of the pile body and send it to the controller of the charging pile.
  • the second temperature sensor can be used to detect the real-time temperature value of the charging gun and send it to the controller.
  • the current sensor can be used to detect the real-time current value flowing through the charging gun and send it to the controller.
  • the voltage sensor can be used to detect the real-time voltage value at the tip of the charging gun and send it to the controller.
  • the pressure sensor can be used to detect the pressure value between the tip of the charging gun and the body of the charging pile and send it to the controller.
  • this step may be performed by the charging pile 160 (for example, the determination module 430).
  • the abnormal state data may include abnormal state data of the operable parts of the charging pile, abnormal interaction data between the charging pile and the vehicle, and the like.
  • the abnormal state data of the operable parts of the charging pile may include abnormally pulling out the charging gun, abnormally opening the charging cabinet door, abnormally pressing the emergency stop button, and so on.
  • the abnormal interaction data between the charging pile and the vehicle may include abnormal communication connection between the charging pile and the charged vehicle (for example, connection timeout, connection failure), abnormal current battery data of the vehicle fed back to the charging pile by the charged vehicle, and the like.
  • the charging pile may pre-store the standard range of the charging state data of the charging pile (for example, the standard state data table).
  • the standard range of the charging state data of the charging pile refers to the standard range of the charging state data of the charging pile in the normal working state.
  • the standard state data table may include the standard range of the temperature of the pile body, the standard range of the current of the charging gun tip, the standard range of the voltage of the charging gun tip, and so on.
  • the charging pile may include a sensor that detects the current of the charging gun.
  • the current value of the charging gun will change.
  • the sensor detects that the current value does not change as normal, it can be considered that the user has not successfully connected the charging gun.
  • the current of the charging gun also changes regularly. If the current value of the charging gun suddenly changes to zero during charging, it can be considered that the charging gun has disconnected from the vehicle, and the charging gun is considered to be abnormally pulled out. .
  • the corresponding sensor in the charging pile can detect whether the charging cabinet door is abnormally opened, whether the emergency stop button is abnormally pressed, and so on.
  • the charging pile can obtain the response time of the charged vehicle. If the response time of the charged vehicle exceeds a set threshold, it is considered that the communication connection between the charging pile and the charged vehicle is abnormal.
  • the response time of the charged vehicle is obtained by: sending a charging signal to the charged vehicle during the current charging operation; acquiring the response signal fed back by the charged vehicle according to the charging signal; The interval between the receiving time of the response signal and the sending time of the charging signal is the response time of the charged vehicle.
  • the charging pile needs to communicate with the charged vehicle to obtain battery information of the charged vehicle, so as to adjust the charging speed, output power, etc. according to the battery information.
  • the charging pile cannot successfully communicate with the vehicle at this time, and the vehicle battery data cannot be obtained, the order may not continue, and an abnormal order may occur.
  • the authentication result, relay voltage, communication function of the battery management system, the insulation of the power battery and the connector function of the charged vehicle can also be tested during the charging process.
  • 640 in response to determining that the charging state data includes the abnormal state data, it is determined that the order is an abnormal order, and an identifier corresponding to the abnormal state data is generated for the abnormal order.
  • This step may be performed by the charging pile 160 (for example, the determination module 430).
  • the abnormal order may refer to an order in which the charging operation is not normally completed due to abnormal status data. For example, if the charging pile cannot be connected to the vehicle due to damage to the charging gun connection device, the order cannot be completed normally.
  • an abnormal order may also refer to an order in which the charging operation can still be completed normally although the charging state data includes abnormal state data. For example, during the charging process of the vehicle, the communication between the charging pile and the vehicle is interrupted for a period of time, and then the communication is resumed. At this time, the charging operation can still be completed.
  • order abnormalities caused by different types of charging status data abnormalities are assigned different identifiers. For example, in response to determining that the state data of the operable component of the charging pile is an abnormal state, a first identifier is generated for the abnormal order. That is, the first identifier indicates that the order is abnormal due to the abnormality of the operable component. For another example, in response to determining that the interaction data is in an abnormal state, a second identifier is generated for the abnormal order. That is, the second identifier indicates that the order is abnormal due to abnormal communication between the charging pile and the charged vehicle.
  • the identifier is used to identify the type of abnormal order.
  • the identifier may be Arabic numerals, letters, characters, codes, etc. or any combination thereof.
  • the identifier can be the letters A, B, C, etc.
  • the identifier may be fault type 1, fault type 2, fault type 3, and so on.
  • the charging pile may obtain the mapping relationship between the abnormal state data and the identifier, and determine the identifier of the abnormal order according to the mapping relationship and the abnormal state data.
  • the mapping relationship between the abnormal state data and the identifier may be determined by a component of the system 100 (for example, the processing device 112) and stored in the storage device (for example, the storage device 150) of the system 100, and the charging pile may be retrieved from the storage device.
  • the mapping relationship may be defined and issued by the charging pile server, and determining the identifier according to the mapping relationship issued by the server can provide a data basis for accurately locating the cause of the abnormality.
  • one abnormal order may correspond to multiple identifiers. For example, if the abnormal status data corresponding to a certain order includes the communication connection timeout between the charging pile and the charged vehicle, the charging gun is abnormally pulled out, and the emergency stop button is abnormally pressed, and the state data of the operable parts of the corresponding charging pile is The identifier of the abnormal state is set to A, and the identifier corresponding to the abnormal state of the interaction data between the charging pile and the vehicle is set to B, the charging pile can determine that the order is an abnormal order, and generate an identifier A+B for the abnormal order .
  • an identifier can be assigned to each abnormal order information, and different identifiers can represent different abnormal reasons. Therefore, the server can quickly locate the abnormal reason according to the identifier when determining the abnormal order.
  • the abnormal order is sent to a server connected to the charging pile. This step may be performed by the charging pile 160 (for example, the control module 440).
  • the charging pile may send the abnormal order including the identifier to a server (for example, the server 110) connected to the charging pile via a network (for example, the network 120).
  • a server for example, the server 110
  • the server After the server obtains the abnormal order, it can determine the reason for the abnormal order based on the identifier. More descriptions on determining the abnormal cause of abnormal orders can be found elsewhere in this application (for example, Figure 7 and related descriptions).
  • the reason for the abnormal charging order can be determined according to the charging state data, and different identifiers are configured for the abnormal order caused by different reasons. Therefore, when the server receives the abnormal order information, it can determine the reason for the abnormal order according to the identifier.
  • the actual cause of the order abnormality can be determined, thereby improving the efficiency of subsequent troubleshooting, and there is no need to send maintenance personnel to the site to inspect and repair the charging pile for reasons that are not caused by the charging pile failure. Therefore, waste of resources can be avoided.
  • operation 620 and operation 630 may be combined into one operation.
  • operation 610 may be omitted, and the server may generate a charging order based on the charging request, and send the charging order to the charging pile.
  • FIG. 7 is a flowchart of an exemplary process 700 for determining the abnormal cause of an abnormal order according to some embodiments of the present application.
  • the process 700 can be executed by the system 100.
  • one or more operations of the process 700 shown in FIG. 7 may be implemented in the system 100 shown in FIG. 1.
  • the process 700 shown in FIG. 7 may be stored in a storage device in the form of instructions, and called and/or executed by the server 110 (for example, the processing device 112).
  • the server 110 for example, the processing device 112
  • the operation of the flow shown below is for illustrative purposes only.
  • the process 700 may include one or more additional operations not described and/or one or more operations not discussed.
  • the operation sequence of the flow shown in FIG. 7 and described below is not restrictive.
  • the information of the abnormal order is obtained.
  • the information of the abnormal order reflects that there is abnormal state data during the charging operation of the charging pile, and the information of the abnormal order includes an identifier corresponding to the abnormal state data.
  • This step may be executed by the processing device 112 (for example, the acquisition module 510).
  • the processing device 112 may communicate with a charging pile (for example, the charging pile 160), so as to obtain information about abnormal orders from the charging pile.
  • the charging pile may send the abnormal order information to the processing device 112 via the network 120 in real time.
  • the processing device 112 may periodically (for example, daily, weekly, monthly) obtain information about abnormal orders from the charging pile.
  • the processing device 112 obtains the information of the abnormal order from the charging pile.
  • the charging pile may send the information of the abnormal order to the storage device (for example, the storage device 150) of the system 100, and the processing device 112 may obtain the information of the abnormal order from the storage device.
  • the abnormal order information can reflect the situation of abnormal state data when the charging pile is performing the charging operation.
  • the information of the abnormal order may include an identifier corresponding to the abnormal state data, that is, the identifier may indicate the type of the abnormal state. More descriptions of abnormal state data and identifiers can be found elsewhere in this application (for example, Figure 6 and related descriptions).
  • the abnormal cause of the abnormal order is determined according to the identifier. This step may be executed by the processing device 112 (for example, the determination module 520).
  • the abnormal reasons for abnormal orders can be divided into three categories, including but not limited to the following: charging pile failure (pile responsibility), vehicle failure (car responsibility), and abnormal operation ( Human responsibility).
  • charging pile failure (pile responsibility) can be understood as an order abnormality caused by charging pile failure, such as network module failure, charging gun connection device damage, cabinet door cannot be closed normally, emergency stop button failure, etc.
  • Abnormal operation (personal responsibility) can be understood as an order abnormality caused by incorrect operation by the user, such as charging without inserting the gun, pulling the gun during charging, opening the cabinet door not as required, pressing the emergency stop button in violation of regulations, etc.
  • Vehicle failure (car liability) can be understood as an order abnormality caused by the interaction between the vehicle and the pile, for example, the vehicle does not respond to the battery information query of the charging pile in time, and the charging information reported by the charging vehicle is inaccurate.
  • the charging pile assigns identifiers to abnormal orders. Different identifiers can indicate different abnormal state data types. According to different abnormal state data types, it can be determined whether it is caused by charging pile failure, vehicle failure, or improper operation. Abnormal orders.
  • the processing device 112 may obtain charging pile information corresponding to the abnormal order.
  • the charging pile corresponding to the abnormal order refers to the charging pile that generates the abnormal order, that is, the charging pile that charges the vehicle in the abnormal order.
  • the processing device may extract charging pile information (for example, the geographic location of the charging pile, the number of the charging pile) from the information of the abnormal order.
  • the processing device 112 may obtain the information of the historical abnormal order corresponding to the charging pile information in the historical time period, and obtain the historical identifier in the information of the historical abnormal order.
  • the historical time period may be a default value stored in a storage device (for example, the storage device 150). Additionally or alternatively, the historical time period may be manually set according to different situations or determined by one or more components of the system 100. For example, the historical time period may be in the last week, in the last month, in the last three months, and so on.
  • the processing device may obtain information about all historical abnormal orders generated by charging piles corresponding to abnormal orders in the last week, and extract historical identifiers in the historical abnormal order information. Further, the processing device 112 may determine the abnormal reason of the abnormal order according to the proportion of the identifier (corresponding to the current abnormal state data) in the historical identifier.
  • the identifier is a first identifier
  • the first identifier may indicate that the state data of the operable component of the charging pile is an abnormal state.
  • Such reasons may be improper operation by the user, such as unsuccessful connection of the charging gun, unplugging the gun during charging, failing to open the cabinet door according to regulations, pressing the emergency stop button in violation of regulations, etc., or the charging pile itself malfunctions, for example, the terminal of the charging gun is loose As a result, the normal connection cannot be made, the cabinet door cannot be closed normally, and the emergency stop button malfunctions.
  • the order abnormality caused by this type of reason should account for a large proportion (for example, close to or even 100%) in the historical period of time, and if it is improper human operation, the order abnormality caused by this type of reason It should be sporadic and its proportion should be small. Therefore, it can be judged whether the charging pile is malfunctioning or man-made abnormal operation according to the proportion of the abnormal reason in the historical order.
  • the processing device 112 may determine whether the proportion of the first identifier in the historical identifier is greater than a threshold.
  • the threshold may be a default parameter stored in a storage device (for example, the storage device 150). Additionally or alternatively, the threshold may be manually set according to different situations or determined by one or more components of the system 100. For example, the threshold can be set to 90%. In response to determining that the proportion of the first identifier in the historical identifier is greater than the threshold, it is determined that the cause of the abnormality is a failure of the charging pile. In response to determining that the proportion of the first identifier in the historical identifier is less than the threshold, it is determined that the cause of the abnormality is an abnormal operation.
  • the identifier of an abnormal order acquired by the processing device 112 is the first identifier
  • the charging pile corresponding to the abnormal order is the No. 1 charging pile
  • the No. 1 charging pile extracted by the processing device 112 was generated in the past week
  • the historical abnormal order information is: 8 times that the charging pile cabinet door is abnormally closed, 10 times that the charging gun is abnormally pulled out, and 2 times that the network connection fails.
  • the identifier is a second identifier, and the second identifier indicates that the interaction data between the charging post and the vehicle being charged is in an abnormal state.
  • This type of reason may be a malfunction of the charging pile or a malfunction of the vehicle being charged. If the charging pile itself fails, the order abnormality caused by this type of reason should account for a large proportion (for example, close to or even 100%) in the historical time period, and if the charged vehicle fails, the order caused by this type of reason The abnormality should be sporadic and its proportion should be small. Therefore, it can be judged whether the charging pile is faulty or the vehicle is faulty according to the proportion of the abnormal reason in the historical order.
  • the processing device 112 can determine whether the proportion of the second identifier in the historical identifier is greater than a threshold. In response to determining that the proportion of the second identifier in the historical identifier is greater than the threshold, it is determined that the cause of the abnormality is a failure of the charging pile. In response to determining that the proportion of the second identifier in the historical identifier is less than the threshold, it is determined that the cause of the abnormality is a vehicle failure.
  • the server after the server receives the abnormal order information reported by the charging pile, it automatically uses the charging station, the operator, etc., according to the predefined identifier according to a certain historical time period (for example, one day, one week).
  • the aggregation algorithm performs statistical analysis on the abnormality of the order to determine the cause of the abnormality.
  • the processing device 112 may generate a mapping relationship between the abnormal state data and the identifier, and send the mapping relationship to the charging pile. This can ensure that the identifier in the abnormal order information reported by the charging pile and the identifier defined by the platform server have a unified standard.
  • the process 700 may further include generating a mapping relationship between the reason for the abnormality and the processing personnel, and sending the reason for the abnormality to the terminal of the corresponding processing personnel.
  • the processing device 112 may determine the terminal corresponding to the reason for the abnormality according to the plan information, and send the reason for the abnormality to the terminal.
  • the plan information may record the cause of the abnormality, the corresponding relationship between the processing personnel and the terminals of the processing personnel.
  • the processing device 112 may send the reason for the abnormality to the processing personnel via SMS according to the mobile phone number reserved by the processing personnel.
  • the server can take automated message push measures for abnormal reasons to promote follow-up and resolution by relevant responsible parties, thereby reducing the order abnormality rate.
  • the server can push the charging pile fault to the charging pile maintenance personnel, which can locate the fault to the specific charging pile or even the charging gun, and help the maintenance personnel to quickly repair the charging pile. If, after statistics, it is found that the charging pile of a certain charging station frequently generates abnormal orders, the server can push the charging pile fault of the charging station to the person in charge of the charging station. Furthermore, if after statistics, it is found that a certain brand or even certain batches of charging piles frequently generate abnormal orders, then it can be suspected that the modules used by the charging piles of this batch are defective, and the server can automatically generate an alarm message, such as connecting the charging piles. The fault is reported to the person in charge of the charging pile brand, and they are asked to help troubleshoot the problem.
  • the server may push the abnormal reason to the user to help the user standardize the operation. Since operations that do not follow the prescribed procedures will cause great security risks, effective methods must be adopted to restrain users. For example, for unauthorized removal of a gun during charging, the server can push the cause of the abnormality to the user through the APP, and at the same time push the safety operation specification, or disable the account for 1 day and require the user to sign a safety operation manual, etc., to help users form a good safety concept and reduce Security Risk.
  • the server may push the abnormal cause to the user to remind the user that the vehicle may be malfunctioning .
  • the server can automatically notify the user through APP notifications, text messages, etc., so that the user can repair the vehicle.
  • the server may implement a monitoring alarm mechanism when counting the reasons for the abnormality of the order.
  • the maintenance personnel of charging piles can subscribe to the statistics of abnormal orders of specific piles according to their own maintenance area.
  • the server needs to provide such message subscription channels, such as e-mail, IM messages, etc., through this way to form a unified
  • This kind of active problem discovery and resolution mechanism breaks the previous dilemma of passively waiting to report problems, thereby improving the availability of equipment.
  • the person in charge of the charging station can also have an overall understanding of the situation of the station equipment he is responsible for by subscribing to the order summary of the charging station.
  • the situation of the responsible party can be clarified, and the root cause of the abnormality can be located automatically, quickly and accurately, and the relevant personnel can be promoted to implement improvement plans, which can greatly reduce the order abnormality rate and additionally improve the safety of user operations.
  • FIG. 8 is a flowchart of an exemplary process 800 for monitoring charging piles according to some embodiments of the present application.
  • the process 800 can be executed by the system 100.
  • one or more operations of the process 800 shown in FIG. 8 may be implemented in the system 100 shown in FIG. 1.
  • the process 800 shown in FIG. 8 may be stored in a storage device in the form of instructions, and called and/or executed by the server 110 (for example, the processing device 112).
  • the server 110 for example, the processing device 112
  • the operation of the flow shown below is for illustrative purposes only.
  • the process 800 may include one or more additional operations not described and/or one or more operations not discussed.
  • the operation sequence of the flow shown in FIG. 8 and described below is not restrictive.
  • the charging pile may communicate with a server (for example, the processing device 112), upload a charging order to the server (for example, the processing device 112), and report the reason for stopping charging.
  • a server for example, the processing device 112
  • upload a charging order to the server for example, the processing device 112
  • report the reason for stopping charging For example, when a user uses a charging pile to charge, he can scan a code through a client terminal (for example, a mobile phone) to request charging, and in response to the charging request, the charging pile starts to charge the vehicle. After the charging is completed, the charging pile can communicate with the server for orders, and the charging pile uploads the charging order to the server and reports the reason for stopping charging.
  • the processing device 112 may obtain order information from the charging pile via the network 120 in real time. In some embodiments, the processing device 112 may periodically (for example, daily, weekly, monthly) obtain order information from the charging station through the network 120.
  • Reasons for stopping charging may include normal stopping and abnormal stopping.
  • the normal stop of the charging order may be caused by the end of charging, insufficient user account fees, and other reasons.
  • the abnormal stop of the charging order may be caused by charging pile failure, vehicle failure, abnormal operation, etc. If the reason for stopping charging is normal stopping, the corresponding order may be determined to be a normal order, and the processing device 112 may no longer analyze it. If the reason for stopping charging is an abnormal stop, the corresponding order may be determined to be an abnormal order, and the processing device 112 may further analyze the information of the abnormal order to determine the abnormal cause of the abnormal order.
  • the description of determining the abnormal cause of the abnormal order can be found elsewhere in this application (for example, operation 720 and its description in FIG. 7).
  • This step may be executed by the processing device 112 (for example, the determination module 520).
  • the number of abnormally stopped charging orders associated with the charging pile if within a historical time period (for example, in the last day, in the last week, in the last month, in the last three months), the number of abnormally stopped charging orders associated with the charging pile The proportion of all orders related to the charging pile is greater than the proportion threshold, and the reason for the abnormal stop is the failure of the charging pile, then it is determined that the charging pile is an abnormal charging pile. In some embodiments, if within a historical time period (for example, in the last day, in the last week, in the last month, in the last three months), the number of abnormally stopped charging orders associated with the charging pile If it is greater than the number threshold, and the reason for the abnormal stop is the failure of the charging pile, it is determined that the charging pile is an abnormal charging pile.
  • the charging pile is an abnormal charging pile. More descriptions on determining abnormal charging posts can be found elsewhere in this application (for example, operation 920 and its description in FIG. 9).
  • Step 830 Perform a monitoring operation on the abnormal charging pile. This step may be performed by the processing device 112 (for example, the control module 530).
  • the monitoring operations may include isolation operations and repair operations. More descriptions on the monitoring operation of the charging pile can be found elsewhere in this application (for example, as shown in Figure 9 and its description).
  • the charging pile is abnormal. If the actual charging is OK, it means that there is no problem with the charging pile at this time. Since the function of the charging pile is to charge, whether the charging order is abnormal can fully indicate whether the charging function of the charging pile is normal. Therefore, by analyzing the charging order generated by the charging pile during the actual charging process, the failure of the charging pile can be found in a timely and accurate manner. According to some embodiments of the present application, by analyzing the order generated during charging of the charging pile, the order analysis result is used as the basis for fault judgment, so that the fault detection of the charging pile is more accurate and timely.
  • the charging pile can determine the abnormal order according to the charging status data, and send the abnormal order to the server, as shown in Figure 6 and its related description; after the server receives the abnormal order, if the abnormal reason for the abnormal order is determined to be the charging pile failure , It can be determined that the charging pile corresponding to the abnormal order is an abnormal charging pile, and the monitoring operation of the abnormal charging pile is performed, as shown in Fig. 8 and related descriptions.
  • FIG. 9 is a flowchart of an exemplary process 900 for monitoring charging piles according to some embodiments of the present application.
  • the process 900 may be executed by the system 100.
  • one or more operations of the process 900 shown in FIG. 9 may be implemented in the system 100 shown in FIG. 1.
  • the process 900 shown in FIG. 9 may be stored in a storage device in the form of instructions, and called and/or executed by the server 110 (for example, the processing device 112).
  • the server 110 for example, the processing device 112
  • the operation of the flow shown below is for illustrative purposes only.
  • the process 900 may include one or more additional operations not described and/or one or more operations not discussed.
  • the operation sequence of the flow shown in FIG. 9 and described below is not restrictive.
  • This step may be executed by the processing device 112 (for example, the determination module 520).
  • the charging pile is set as an abnormal charging pile. For example, if five consecutive charging orders are abnormally stopped, and the reason for the abnormal stop is the abnormal charging pile, then the charging pile is set as the abnormal charging pile.
  • an isolation operation is performed on the abnormal charging pile. This step may be performed by the processing device 112 (for example, the control module 430).
  • the processing device 112 may isolate the abnormal charging pile.
  • the isolation operation includes: in response to obtaining a charging request from a client, if the charging pile requested by the charging request is the abnormal charging pile, returning the abnormal charging pile information to the client, and/ Or provide the client with the guidance information of other normal charging piles other than the abnormal charging pile. For example, when a driver scans and charges an abnormal charging pile, he proactively informs the driver that the charging pile is abnormal and prompts the driver to go to other charging piles at the current charging station to charge. This allows the driver to immediately perceive the abnormality of the charging pile, improve the operating efficiency of the overall charging station, and save the driver's time.
  • repair the abnormal charging pile may be performed by the processing device 112 (for example, the control module 530).
  • the charging pile may be repaired to realize the maintenance of the abnormal charging pile.
  • the repair operation includes: determining whether the version of the abnormal charging pile is the latest available version, in response to determining that the version of the abnormal charging pile is the latest available version, sending a restart instruction to the abnormal charging pile; If the version of the abnormal charging pile is not the latest available version, an upgrade instruction is sent to the abnormal charging pile.
  • it can also provide an automatic repair function for abnormal charging piles, making the repairing of charging piles more efficient.
  • the terminal of the corresponding processing personnel will be sent about the abnormal charging pile Maintenance work order. This step may be performed by the processing device 112 (for example, the control module 530).
  • the preset time period may be a default parameter stored in a storage device (for example, the storage device 150). Additionally or alternatively, the preset time period may be manually set according to different situations or determined by one or more components of the system 100. For example, the preset time period may be 12 hours, 24 hours, one week, and so on.
  • the storage device (for example, the storage device 150) of the system 100 may pre-store the mapping relationship between the charging pile and the processing personnel and/or the mapping relationship between the cause of the failure of the charging pile and the processing personnel.
  • the processing device 112 can determine the corresponding processing personnel based on the information of the abnormal charging pile (for example, the number of the charging pile, the geographic location of the charging pile) and/or the cause of the malfunction of the abnormal charging pile (for example, the gun head failure, the cabinet door failure) . Further, the processing device may send a maintenance work order regarding the abnormal charging pile to the terminal of the corresponding processing personnel.
  • the maintenance work order can include information about abnormal charging piles (for example, abnormal charging pile number, abnormal charging status data, abnormal charging pile historical maintenance records), information of charging stations where abnormal charging piles are located (for example, charging station geographic location, charging station number , The number of charging piles in the charging station), etc.
  • the processing personnel can repair the abnormal charging pile based on the information of the abnormal charging pile.
  • Step 960 After performing the repair operation, if the abnormal order information sent by the abnormal charging pile is not received within a preset time period, set the abnormal charging pile as a normal charging pile. This step may be performed by the processing device 112 (for example, the control module 530).
  • the processing device 112 no longer performs an isolation operation on the charging pile, and the user can use the charging pile normally.
  • operation 930 and operation 940 may be performed in synchronization.
  • operation 930 or operation 940 may be omitted.
  • other methods can be used to deal with it (for example, remind the user, save the record) ).
  • the abnormal cause of the abnormal order is a vehicle failure
  • a reminder about the vehicle failure can be sent to the user terminal.
  • a reminder of safe operation specifications may be sent to the user terminal. More descriptions about the handling of abnormal reasons for abnormal orders can be found elsewhere in this application (for example, FIG. 7 and its description).
  • FIG. 10 is a flowchart of an exemplary process 1000 of a charging pile monitoring method according to some embodiments of the present application.
  • a user e.g., a driver initiates a charging request.
  • the driver can initiate a charging request to the charging pile through the user interface (for example, an application) of the client terminal.
  • the driver can initiate a charging request by scanning the QR code on the charging pile using the client terminal.
  • step 1003 in response to the charging request initiated by the user, the server returns whether the charging pile is normal. If the charging pile is abnormal, step 1003 is executed to isolate the charging pile. If the charging pile is normal, step 1004 is executed.
  • the charging post performs charging operations on the vehicle.
  • the charging pile stops charging.
  • FIG. 11 is a flowchart of an exemplary process 1100 for identifying a fault of a charging pile according to some embodiments of the present application.
  • the process 1100 may be executed by the system 100.
  • one or more operations of the process 1100 shown in FIG. 11 may be implemented in the system 100 shown in FIG. 1.
  • the process 1100 shown in FIG. 11 may be stored in a storage device in the form of instructions, and called and/or executed by the server 110 (for example, the processing device 112).
  • the server 110 for example, the processing device 112
  • the operation of the flow shown below is for illustrative purposes only.
  • the process 1100 may include one or more additional operations not described and/or one or more operations not discussed.
  • the operation sequence of the flow shown in FIG. 11 and described below is not restrictive.
  • the time point when the server receives the current communication data is acquired, and the communication data is sent by the charging pile.
  • This step may be executed by the processing device 112 (for example, the acquisition module 510).
  • the communication data can include heartbeat signals and charging status data.
  • the heartbeat signal refers to the data sent to the server by the charging pile in the working state (including the charging process and the non-charging process) (for example, the cumulative charging amount, the pile power, the cumulative charging duration, the cumulative charging amount).
  • each charging pile will periodically or irregularly send communication data to the server in order to "prove” that it is working. This is generally called a "heartbeat packet" or "heartbeat signal”.
  • the charging status data refers to the data sent by the charging pile to the server during the charging process.
  • the charging status data can include the status data of the charging pile (for example, the status data of the operable parts of the charging pile), the interaction data between the charging pile and the vehicle, the reminder signal sent when the charging is started or ended, the charging process and the charging amount calculation Relevant signals, billing data sent after charging, etc., are as described elsewhere in this application (for example, FIG. 6 and related descriptions).
  • the charging pile will report charging process data (for example, charging power, charging time) regularly or irregularly. After charging is completed, the charging pile will also report charging bill data to the server. Therefore, in theory, as long as the server receives the data reported by the charging pile at any stage reported by the charging pile, it can be considered that the charging pile is online at that moment.
  • the charging pile can send communication data to the server (for example, the processing device 112). After the server receives the communication data, it can directly determine that the communication is received this time. The moment of data.
  • 1120 using the time point as a starting point, it is determined whether the server receives new communication data within a preset first time threshold. This step may be executed by the processing device 112 (for example, the determination module 520).
  • the first time threshold may be a default value stored in a storage device (for example, the storage device 150). Additionally or alternatively, the first time threshold may be manually set according to different situations or determined by one or more components of the system 100. In some embodiments, the first time threshold may be determined according to the network stability of the location where the charging pile is located. The stability of the network can be related to the brand of the charging pile and the network operator. For example, for areas with strong network signal coverage, the first threshold can be set relatively short (for example, between 5-8 minutes). For areas with weak network signal coverage, the first threshold can be set relatively long (for example, about 15 minutes).
  • the types of the new communication data and the current communication data may be the same or different, as long as they are the communication data obtained from the charging pile.
  • This step may be executed by the processing device 112 (for example, the determination module 520).
  • the presence of an offline fault point in the charging pile may mean that the charging pile is offline at a certain point in time.
  • the reason for the offline failure point of the charging pile may be the charging pile failure or the network instability (for example, the temporary disconnection caused by the network jitter).
  • the offline failure point may be associated with any time point between the current reception time point of the communication data and the time point after the current reception time plus the first time threshold.
  • the offline fault point can be associated with the receiving time point of the current communication data, or can be associated with the time point after the current receiving time plus the first time threshold.
  • the offline failure point is generated at the time of receiving the current communication data, or it can be considered that the offline failure point is generated at the time of receiving the current communication data plus the first time threshold, or the above two Generated between time points.
  • the processing device 112 receives communication data from charging pile No. 1 at 8:00 on June 1, 2020, the first time threshold is 10 minutes, and the processing device 112 is at 8:10 on June 1, 2020. If the new communication data has not been received, the processing device 112 can consider that there is an offline fault point in the charging pile No. 1, and the generation time of the offline fault point can be considered to be any time point between 8:00 and 8:10.
  • the processing device 112 may further determine whether the charging pile has a failure. In some embodiments, the processing device 112 may determine whether there are continuous offline fault points in the charging pile and whether the number of the continuous offline fault points exceeds a fault point threshold. The existence of continuous offline fault points of the charging pile can reflect that the charging pile is offline at multiple consecutive time points, and it can be determined that the reason for the charging pile offline is the failure of the charging pile rather than the unstable network. In response to determining that the charging pile has continuous offline failure points and the number of the continuous offline failure points exceeds the failure point threshold, it is determined that the charging pile has a failure. For example, if there are 5 consecutive offline fault points in the charging pile, it is determined that the charging pile is faulty.
  • the processing device 112 may determine whether the server has not received new communication data within a preset second time threshold.
  • the second time threshold is greater than the first time threshold.
  • the second time threshold may be selected as a multiple of the first time threshold. For example only, when the first time threshold is set to 15 minutes, the second time threshold may be set in the range of 1.5 hours to 2 hours.
  • the processing device 112 may determine that the charging pile is faulty.
  • the server can always record the time track of the communication data reported by the charging pile to be identified. If no communication data is received after the first time threshold is exceeded, it can be determined that the charging pile has an offline fault. Point, the offline fault point can be associated with the receiving time of this communication data, or it can be associated with the time point after the first time threshold is added to the current receiving time. If multiple failure points (for example, more than four) occur continuously, it can be determined that the charging pile to be identified has an offline failure. This method can eliminate the misjudgment of an offline fault due to occasional signal jitter, and improve the accuracy of offline fault identification.
  • the second preset time is already a long period of time. If the new communication data cannot be received after the second preset time, it can be directly determined that the charging pile has an offline fault.
  • the process 1100 may further include other steps. For example, in response to determining that the charging pile has an offline fault point, the processing device 112 may obtain the device attribute of the charging pile and the first terminal attribute corresponding to the device attribute of the charging pile. The processing device 112 may send fault reminding information to the first terminal according to the attributes of the first terminal, where the fault reminding information includes the device attributes of the charging pile.
  • the processing device 112 may obtain the proportion of the charging piles that are determined to have offline fault points in the charging station to the total number of charging piles, and the processing device 112 may determine whether the proportion exceeds a threshold, and in response to determining that the proportion exceeds the threshold , The processing device 112 may obtain the site attributes of the charging station and the second terminal attributes corresponding to the site attributes, and the processing device 112 may send alarm information to the second terminal according to the second terminal attributes, and the alarm information includes The site attributes of the charging station. More descriptions about sending fault reminder information and alarm information can be found elsewhere in this application (for example, Figure 13 and related descriptions).
  • operation 1120 and operation 1130 may be omitted.
  • the processing device 112 may directly determine that the charging pile is faulty.
  • the sensors inside the charging pile can detect the actual status data of the charging pile. If the status data of a certain component is found to be abnormal, the charging pile can generate fault information and use the fault information as part of the communication data. Report to the server. After the server receives the fault information, it can determine that the charging pile has an offline fault. However, if the network fails and the server has been unable to successfully receive the failure information, at this time, the charging pile can be detected for failure through the process 1100. Therefore, according to some embodiments of the present application, it is possible to identify the fault of the charging pile by combining two methods of active reporting of the charging pile and passive detection by the server, so as to find the fault of the charging pile in a more timely manner.
  • FIG. 12 is a flowchart of an exemplary process 1200 for identifying a fault of a charging pile according to some embodiments of the present application.
  • the process 1200 can be executed by the system 100.
  • one or more operations of the process 1200 shown in FIG. 12 may be implemented in the system 100 shown in FIG. 1.
  • the process 1200 shown in FIG. 12 may be stored in a storage device in the form of instructions, and called and/or executed by the server 110 (for example, the processing device 112).
  • the operation of the flow shown below is for illustrative purposes only.
  • the process 1200 may include one or more additional operations not described and/or one or more operations not discussed.
  • the operation sequence of the flow shown in FIG. 12 and described below is not restrictive.
  • the time point when the server receives the current communication data is acquired, and the communication data is sent by the charging pile.
  • This step may be executed by the processing device 112 (for example, the acquisition module 510).
  • an order abnormality identifier is generated for the abnormal order. This step may be executed by the processing device 112 (for example, the determination module 520).
  • the processing device 112 may determine whether the charging state data in the current communication data includes abnormal state data. In response to determining that the charging state data includes abnormal state data, the processing device 112 may determine that the order is an abnormal order, and generate an order abnormality identifier (for example, a first identifier, a second identifier) for the abnormal order. In some embodiments, as shown in the related description of FIG. 6, the charging pile can determine whether the charging state data includes abnormal state data, and if it is determined that the charging state data includes abnormal state data, it is determined that the order is an abnormal order, and An identifier corresponding to the abnormal state data is generated for the abnormal order, and the identifier is further sent to the processing device 112.
  • an order abnormality identifier for example, a first identifier, a second identifier
  • the execution body of the operation of generating an identifier for an abnormal order may be the charging pile or the processing device 112, and this application does not make any restrictions.
  • the description of generating identifiers for abnormal orders can be found elsewhere in this application (for example, Figure 6 and related descriptions).
  • the number of historical abnormal orders and the total number of historical orders of the charging pile are obtained. This step may be executed by the processing device 112 (for example, the acquisition module 510).
  • the processing device 112 may count the number of historical abnormal orders related to the charging pile in the first historical time period and the total number of historical orders related to the charging pile in the second historical time period.
  • the first historical time period and the second historical time period may be different.
  • the first historical time period and the second historical time period may be the same, thereby reducing the amount of data analysis and improving efficiency.
  • the historical time period (for example, the first historical time period, the second historical time period) may be a default value stored in the storage device (for example, the storage device 150).
  • the historical time period (for example, the first historical time period, the second historical time period) may be manually set according to different situations or determined by one or more components of the system 100.
  • the historical time period may be the last three days, the last week, the last month, the last three months, and so on.
  • this step may be executed by the processing device 112 (for example, the determination module 520).
  • this step may be executed by the processing device 112 (for example, the determination module 520). In response to determining that the proportion of the number of historical abnormal orders of the charging pile to the total number of historical orders does not exceed the proportion threshold, it is determined that the charging pile is not faulty.
  • the ratio threshold may be a default value stored in a storage device (eg, storage device 150). Additionally or alternatively, the ratio threshold may be manually set according to different situations or determined by one or more components of the system 100. In some embodiments, the ratio threshold can be set between 30%-50%. As an example only, assuming that the ratio threshold is set to 50%, if a charging pile has more than 50% of abnormal billing information in the past three days, it can be considered that the charging pile is faulty.
  • FIG. 13 is a flowchart of an exemplary process 1300 for identifying a fault of a charging pile according to some embodiments of the present application.
  • the process 1300 may be executed by the system 100.
  • one or more operations of the process 1300 shown in FIG. 13 may be implemented in the system 100 shown in FIG. 1.
  • the process 1300 shown in FIG. 13 may be stored in a storage device in the form of instructions, and called and/or executed by the server 110 (for example, the processing device 112).
  • the operation of the flow shown below is for illustrative purposes only.
  • the process 1300 may include one or more additional operations not described and/or one or more operations not discussed.
  • the operation sequence of the flow shown in FIG. 13 and described below is not restrictive.
  • the time point when the server receives the current communication data is acquired, the communication data is sent by the charging pile, and the communication data includes charging state data.
  • This step may be performed by a processing device (for example, the acquisition module 510).
  • this step may be executed by the processing device 112 (for example, the determination module 520).
  • This step may be executed by the processing device 112 (for example, the acquisition module 510).
  • the processing device 112 may directly extract the status data of the charging pile from the communication data. For another example, if the communication data does not include the status data of the charging post, the processing device 112 may obtain the status data of the corresponding component from the charging post (for example, a sensor).
  • This step may be executed by the processing device 112 (for example, the determination module 520).
  • the preset range of the state data of the charging pile refers to the standard range of the state data of the charging pile in a normal working state.
  • each state data of the operable parts of the charging pile has its corresponding preset standard range.
  • the state data of the charging gun tip may include the preset standard range of the current of the charging gun tip, the preset standard range of the temperature of the charging gun tip, the preset standard range of the voltage of the charging gun tip, and so on.
  • the preset standard range may be pre-stored in a storage device (for example, the storage device 150) of the system 100, and the processing device 112 may obtain the preset standard range from the storage device.
  • the preset standard range may be set by a component of the system 100 (for example, the processing device 112), or may be set by a user of the system 100 according to the model of the charging pile.
  • This step may be executed by the processing device 112 (for example, the determination module 520).
  • the processor 112 may determine that the charging post is faulty. In some embodiments, in response to determining that a certain preset type of state data of the charging pile is not within its corresponding preset range, the processor 112 may determine that the charging pile is faulty. For example, only when it is determined that the state data of the charging gun or the pile body of the charging pile is not within the corresponding preset range, it is determined that the charging pile has a fault.
  • the fault reminder information is sent to the first terminal according to the attributes of the first terminal, and the fault reminder information includes the device attributes of the charging pile. This step may be performed by the processing device 112 (for example, the control module 530).
  • the processing device 112 may obtain the device attribute of the charging post and the first terminal attribute corresponding to the device attribute of the charging post. For example, the processing device 112 may determine the first terminal attribute corresponding to the charging pile device attribute according to the charging pile fault type and/or the correspondence between the charging pile device attribute and the first terminal attribute. The processing device 112 may send fault reminding information to the first terminal according to the attributes of the first terminal.
  • the device attributes of the charging pile may include the information of the charging pile, for example, the charging pile model, the charging pile brand, the charging pile number, and the geographic location of the charging pile.
  • the first terminal may be a communication device (for example, a mobile phone) worn by a processing person (for example, a maintenance person).
  • the first terminal attribute may include the information of the first terminal, for example, the information of the user associated with the first terminal (for example, the identity information of the processing personnel), the model of the first terminal, and so on.
  • the processing device 112 may send a fault reminder message according to a preset communication method, such as SMS, WeChat, and automatic dialing for voice calls, so that the maintenance personnel can repair the faulty charging pile in time.
  • the fault information may include the fault of the charging pile, the information of the charging pile (for example, the number of the charging pile, the geographic location of the charging pile), and the like.
  • the fault information can be text information, voice information, video information, picture information, etc.
  • the proportion of the charging piles determined to be faulty in the charging station to the total number of charging piles is obtained. This step may be performed by the processing device 112 (for example, the acquisition module 510).
  • the processing device 112 may determine the charging station where the faulty charging post is located based on the information of the faulty charging post (for example, the number of the charging post, the geographic location of the charging post).
  • the storage device for example, the storage device 150
  • the processing device 112 may obtain the corresponding relationship between the charging station number and the charging station number from the storage device, and according to the existence
  • the number of the faulty charging pile is to determine the number of the charging station where the faulty charging pile is located.
  • the processing device 112 may count the number of all charging piles determined to be faulty in the charging station and the total number of all charging piles in the charging station. Further, the processing device 112 may determine the proportion of all the charging piles determined to be faulty in the charging station to the total number of charging piles in the charging station.
  • This step may be executed by the processing device 112 (for example, the determination module 520).
  • the threshold may be a default value stored in a storage device (eg, storage device 150). Additionally or alternatively, the threshold may be manually set according to different situations or determined by one or more components of the system 100. For example only, the threshold can be set to 30%, that is to say, when 30% of the charging piles in a charging station have a failure, it can be reported to the person in charge of the charging station.
  • a site attribute of the charging station and a second terminal attribute corresponding to the site attribute are acquired. This step may be executed by the processing device 112 (for example, the determination module 520).
  • the processing device 112 may determine the second terminal attribute corresponding to the site attribute of the charging station according to the correspondence between the station attribute of the charging station and the second terminal attribute.
  • the site attributes of the charging station may include information about the charging station, for example, the geographic location of the charging station, the number of the charging station, the historical order of the charging pile in the charging station, the historical maintenance record of the charging pile in the charging station, etc., or any combination thereof.
  • the second terminal may be a communication device (for example, a mobile phone) worn by a processing person (for example, a person in charge of a charging station).
  • the second terminal attribute may include information of the second terminal, for example, information of the user associated with the second terminal (for example, the identity information of the person in charge of the charging station), the model of the second terminal, and the like.
  • the processing device 112 may send an alarm message according to a preset communication method, such as SMS, WeChat, automatic dialing for voice calls, etc., so that the person in charge of the charging station can handle the failure of the charging station in time.
  • the alarm information may include the information of the charging station (for example, the number of the charging station), the failure of the charging pile in the charging station, the number of charging piles that have failed in the charging station, and the like.
  • the alarm information can be text information, voice information, video information, picture information, etc.
  • the person in charge of the charging station can be notified in time, for example, by sending a short message, sending a WeChat, automatic dialing to make a voice call, etc. , In order to deal with the fault as soon as possible and shorten the time that the charging pile is not available.
  • operation 1370 and operation 1380 may be performed simultaneously.
  • operations 1370 to 1391 or operation 1360 may be omitted.
  • Fig. 14 is a schematic diagram of an exemplary charging monitoring system according to some embodiments of the present application.
  • the charging monitoring system may include a client terminal 1410, a charging pile 1420, a platform server 1430, an electric vehicle 1440, and a handler terminal 1450.
  • the charging pile 1420 may include a plurality of sensors 1421 and a controller 1422.
  • the driver of the electric vehicle 1440 can use the client terminal 1410 to scan the charging code to initiate a charging request to the charging post 1420.
  • the charging pile 1420 may generate a charging order based on the charging request, or send the charging request to the platform server 1430, and the platform server 1430 may coordinate the resources of the charging pile in the charging station (for example, recommend other idle charging piles for the driver), and generate it based on the charging request Charge order.
  • multiple sensors 1421 in the charging post 1420 can detect actual state data of the charging post 1420.
  • the sensor 1421 may include a temperature sensor 1, a current sensor 2, a pressure sensor 3, and so on.
  • the sensor 1421 may send the detected actual state data to the controller 1422.
  • the controller 1422 may determine whether the charging pile 1420 has a fault by determining whether the actual state data is within the corresponding preset standard range. If it is determined that the charging pile 1420 is faulty, the controller 1422 may generate fault information and send the fault information to the platform server 1430. In response to the fault information, the platform server 1430 may generate fault reminder information and send the fault reminder information to the corresponding processor terminal 1450.
  • Fig. 15A is an exemplary schematic diagram of a data transmission process between a charging pile and a platform server according to some embodiments of the present application.
  • the charging pile can periodically or irregularly send a heartbeat signal (also called a "heartbeat package") to the platform server (e.g., cumulative charging amount, pile power, cumulative charging duration, cumulative charging amount).
  • a heartbeat signal also called a "heartbeat package”
  • the platform server e.g., cumulative charging amount, pile power, cumulative charging duration, cumulative charging amount.
  • Fig. 15B is an exemplary schematic diagram of a bill transmission process between a charging pile and a platform server according to some embodiments of the present application.
  • the charging pile can report the charging bill to the platform server.
  • the platform server will send a response message to the charging pile.
  • the charging pile will always try to send bill-related information to the platform server until it receives a response signal from the platform server. If the platform server fails to receive successfully, the platform server can determine whether the charging pile has an offline fault according to the process 1100.
  • Fig. 15C is an exemplary schematic diagram of a fault signal transmission process between a charging pile and a platform server according to some embodiments of the present application.
  • the sensor set inside the charging pile can detect the actual status data of the charging pile.
  • the sensor can send the detected actual state data to the controller of the charging pile, and the controller may determine whether the charging pile is faulty by determining whether the actual state data is within the corresponding preset standard range. If it is determined that the charging pile is faulty, the controller can generate fault information and send the fault information to the platform server. Correspondingly, after receiving the fault information, the platform server will send a response message to the charging pile.
  • the possible beneficial effects of the embodiments of the present application include, but are not limited to: (1) After determining the abnormal charging pile, by isolating and repairing the charging pile that has failed, the repair of the charging pile can be made more efficient and improve The operating efficiency of the entire charging pile; (2) The server can determine whether the charging pile has an offline failure based on the result of whether the new communication data is received within the time threshold after receiving the charging pile data, which can eliminate errors due to occasional signal jitter If it is judged as an offline fault, the accuracy of offline fault identification is improved; (3) The fault of the charging pile can be identified by combining the active reporting of the charging pile and the passive detection of the server, so that the fault of the charging pile can be found in a more timely manner. It should be noted that different embodiments may have different beneficial effects. In different embodiments, the possible beneficial effects may be any one or a combination of the above, or any other beneficial effects that may be obtained.
  • this application uses specific terms to describe the embodiments of the application.
  • “one embodiment”, “an embodiment” and/or “some embodiments” mean a certain feature, structure, or characteristic related to at least one embodiment of the present application. Therefore, it should be emphasized and noted that “one embodiment”, “one embodiment” or “an alternative embodiment” mentioned twice or more in different positions in this specification do not necessarily refer to the same embodiment.
  • some features, structures, or characteristics in one or more embodiments of the present application can be appropriately combined.
  • the computer-readable signal medium may include a propagated data signal containing computer program code, for example on baseband or as part of a carrier wave. Such propagated signals can take many forms, including electromagnetic forms, optical forms, etc., or any suitable combination.
  • the computer-readable signal medium may be any computer-readable medium except a computer-readable storage medium, and the medium may be connected to an instruction execution system, apparatus, or device to realize communication, propagation, or transmission of a program for use.
  • the program code located on the computer-readable signal medium can be transmitted through any suitable medium, including radio, cable, fiber optic cable, RF, etc., or a combination of any of the above media.
  • the computer program code required for the operation of each part of this application can be written in any one or more programming languages, including subject-oriented programming languages such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET, Python, etc. , Conventional programming languages such as C language, VisualBasic, Fortran2003, Perl, COBOL 2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages.
  • the program code can run entirely on the user's computer, or as an independent software package on the user's computer, or partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server.
  • the remote computer can be connected to the user’s computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or can be connected to an external computer (for example, via the Internet), or in a cloud computing In the environment, or as a service (for example, software as a service (SaaS)).
  • LAN local area network
  • WAN wide area network
  • SaaS software as a service

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Water Supply & Treatment (AREA)
  • General Health & Medical Sciences (AREA)
  • Tourism & Hospitality (AREA)
  • Power Engineering (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Primary Health Care (AREA)
  • Human Resources & Organizations (AREA)
  • Development Economics (AREA)
  • Charge And Discharge Circuits For Batteries Or The Like (AREA)

Abstract

一种充电桩故障识别的***和方法。方法包括响应于获取充电请求，对充电请求生成订单（610）；在对车辆执行当前充电操作过程中，获取充电状态数据（620）；确定充电状态数据中是否包括异常状态数据（630）；响应于确定充电状态数据中包括异常状态数据，则确定订单为异常订单，并对异常订单生成与异常状态数据对应的标识符（640）；以及发送异常订单至与充电桩连接的服务器（650）。

Description

充电桩故障识别的***和方法
交叉引用
本申请要求于2019年10月10日提交的申请号为No.201910958433.0的中国申请的优先权，于2019年12月31日提交的申请号为No.201911408140.1的中国申请的优先权，以及于2020年3月11日提交的申请号为No.202010167714.7的中国申请的优先权，其全部内容通过引用并入本文。
技术领域
本申请涉及充电桩故障识别的***和方法，尤其涉及确定充电桩故障的原因以及监控充电桩的***和方法。
背景技术
随着新能源产业的发展，新能源汽车越来越受人们的欢迎，极大满足了人们的日常出行需求。充电桩作为新能源汽车必不可少的充电装置，在日常生活中具有较高的利用率。安全、耐用、操作方便的充电桩对新能源汽车的充电具有关键的作用。在用户使用充电桩的过程中，充电桩通常处于无人值守的自助状态，其工作状态无法得到及时有效的保障，用户在使用充电桩充电的过程中经常遇到充电异常的问题，例如用户违规操作、充电桩故障、被充电车辆故障等。而上述充电异常的问题有时无法由充电站平台准确识别，这在一定程度上影响了用户体验，降低出行效率，不利于社会生产的发展。因此，希望提供一种充电桩故障自动识别和监控的***和方法。
发明内容
本申请一个方面涉及一种充电桩故障识别的方法。所述方法包括：响应于获取充电请求，对所述充电请求生成订单；在对车辆执行当前充电操作过程中，获取充电状态数据；确定所述充电状态数据中是否包括异常状态数据；响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符；以及发送所述异常订单至与所述充电桩连接的服务器。
在一些实施例中，所述充电状态数据包括充电桩可操作部件的状态数据。响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符包括：响应于确定所述充电桩可操作部件的状态数据为异常状态，则对所述异常订单生成第一标识符。
在一些实施例中，所述充电状态数据包括充电桩与所述车辆之间的交互数据。 响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符包括：响应于确定所述交互数据为异常状态，则对所述异常订单生成第二标识符。
在一些实施例中，对所述异常订单生成与所述异常状态数据对应的标识符包括：获取异常状态数据与标识符之间的映射关系；以及根据所述映射关系和异常状态数据，确定所述异常订单的标识符。
本申请的第二个方面涉及一种充电桩故障识别和监控的方法。所述方法包括：获取异常订单的信息，所述异常订单反映充电桩进行充电操作时存在异常状态数据的情况，所述异常订单的信息中包括与所述异常状态数据对应的标识符；以及根据所述标识符，确定所述异常订单的异常原因。
在一些实施例中，所述异常原因包括充电桩故障、车辆故障和非正常操作中的至少一项。
在一些实施例中，根据所述标识符，确定所述异常订单的异常原因，包括：获取与所述异常订单对应的充电桩信息；获取历史时间段内与所述充电桩信息对应的历史异常订单的信息；获取所述历史异常订单的信息中的历史标识符；以及根据所述标识符在所述历史标识符中的所占比例确定所述异常订单的异常原因。
在一些实施例中，所述标识符为第一标识符，所述第一标识符指示所述充电桩的可操作部件的状态数据为异常状态，根据所述标识符，确定所述异常订单的异常原因，包括：确定所述第一标识符在所述历史标识符中的所占比例是否大于阈值。
在一些实施例中，所述方法进一步包括：响应于确定所述第一标识符在所述历史标识符中的所占比例大于所述阈值，则确定所述异常原因为充电桩故障。
在一些实施例中，所述方法进一步包括：响应于确定所述第一标识符在所述历史标识符中的所占比例小于所述阈值，则确定所述异常原因为非正常操作。
在一些实施例中，所述标识符为第二标识符，所述第二标识符指示所述充电桩与被充电的车辆之间的交互数据为异常状态，根据所述标识符，确定所述异常订单的异常原因，包括：确定所述第二标识符在所述历史标识符中的所占比例是否大于阈值。
在一些实施例中，所述方法进一步包括：响应于确定所述第二标识符在所述历史标识符中的所占比例大于所述阈值，则确定所述异常原因为充电桩故障。
在一些实施例中，所述方法进一步包括：响应于确定所述第二标识符在所述历史标识符中的所占比例小于所述阈值，则确定所述异常原因为车辆故障。
在一些实施例中，所述方法进一步包括：生成异常状态数据与标识符之间的映射关系；以及发送所述映射关系至所述充电桩。
在一些实施例中，所述方法进一步包括：生成异常原因与处理人员之间的映射关系；以及发送所述异常原因至相应处理人员的终端。
在一些实施例中，所述异常订单的异常原因是充电桩故障，所述方法进一步包括：确定与所述异常订单对应的充电桩为异常充电桩；以及对所述异常充电桩进行监控操作。
在一些实施例中，确定与所述异常订单对应的充电桩为异常充电桩，包括：如果与所述充电桩相关的多个连续充电订单均为异常停止，且异常停止的原因均为充电桩故障，则确定所述充电桩为异常充电桩。
在一些实施例中，所述监控操作包括隔离操作，所述隔离操作包括：响应于从客户端获取充电请求，如果所述充电请求所请求的充电桩为所述异常充电桩，则向所述客户端返回所述异常充电桩异常的信息，和/或向所述客户端提供异常充电桩以外的其它正常充电桩的引导信息。
在一些实施例中，所述监控操作包括修复操作，所述修复操作包括：确定所述异常充电桩的版本是否为最新可用版本。
在一些实施例中，所述修复操作进一步包括：响应于确定所述异常充电桩的版本为最新可用版本，则向所述异常充电桩发送重启指令。
在一些实施例中，所述修复操作进一步包括：响应于确定所述异常充电桩的版本不是最新可用版本，则向所述异常充电桩发送升级指令。
在一些实施例中，在执行所述修复操作后，如果在预设时间段内仍然接收到所述异常充电桩发送的异常订单的信息，且异常原因为充电桩故障，则向相应处理人员的终端发送关于所述异常充电桩的维护工单。
在一些实施例中，在执行所述修复操作后，如果在预设时间段内未接收到所述异常充电桩发送的异常订单信息，则将所述异常充电桩设置为正常充电桩。
本申请的第三个方面涉及一种充电桩故障识别的方法。所述方法包括：获取服务器接收当前通讯数据的时间点，所述通讯数据由充电桩发送；以所述时间点为起点，确定在预设第一时间阈值内所述服务器是否接收到新的通讯数据；以及响应于确定在预设第一时间阈值内所述服务器没有接收到新的通讯数据，则确定所述充电桩存在离线故障点。
在一些实施例中，所述方法进一步包括：确定所述充电桩是否存在连续的离线故障点且所述连续的离线故障点的个数超过故障点阈值；以及响应于确定所述充电桩存在连续的离线故障点且所述连续的离线故障点个数超过故障点阈值，则确定所述充电桩存在故障。
在一些实施例中，所述方法进一步包括：以所述时间点为起点，确定在预设第二时间阈值内所述服务器是否未接收到新的通讯数据，其中所述第二时间阈值大于所述第一时间阈值；以及响应于确定在预设第二时间阈值内所述服务器没有接收到新的通讯数据，则确定所述充电桩存在故障。
在一些实施例中，所述通讯数据包括心跳信号或充电状态数据。
在一些实施例中，所述充电状态数据包括订单异常信号，所述方法进一步包括：获取所述充电桩的历史异常订单数量和历史订单总数量；确定所述充电桩的历史异常订单数量占历史订单总数量的比例是否超过比例阈值；以及响应于确定所述充电桩的历史异常订单数量占历史订单总数量的比例超过所述比例阈值，则确定所述充电桩存在故障。
在一些实施例中，所述充电状态数据包括充电桩的状态数据，所述方法进一步包括：响应于确定在预设第一时间阈值内所述服务器接收到新的通讯数据，获取所述充电桩的状态数据；确定所述充电桩的状态数据是否在预设范围内；以及响应于确定所述充电桩的状态数据不在所述预设范围内，则确定所述充电桩存在故障。
在一些实施例中，所述充电桩的状态数据包括充电桩的可操作部件的温度、电流值、电压值、充电桩的实时输出功率、充电桩的累计充电时长和充电桩的累计充电量中的至少一项。
在一些实施例中，所述通讯数据包括故障信息，所述方法进一步包括：确定所述充电桩存在故障。
在一些实施例中，所述方法进一步包括：响应于确定所述充电桩存在故障，获取所述充电桩的设备属性以及与所述设备属性对应的第一终端属性；以及根据所述第一终端属性发送故障提醒信息至第一终端，所述故障提醒信息包括所述充电桩的设备属性。
在一些实施例中，所述方法进一步包括：获取充电站中被确定为存在故障的充电桩占充电桩总数的比例；确定所述比例是否超过阈值；响应于确定所述比例超过所述阈值，获取所述充电站的站点属性以及与所述站点属性对应的第二终端属性；以及根据所述第二终端属性发送报警信息至第二终端，所述报警信息包括所述充电站的站点属性。
本申请的第四个方面涉及一种充电桩故障识别和监控的方法。所述方法包括： 获取充电订单的信息，并对充电订单的信息进行分析；如果所述充电订单是异常停止，且异常停止的原因是充电桩异常导致的，则确定所述充电桩为异常充电桩；以及对所述充电桩进行监控操作。
在一些实施例中，确定与所述充电桩为异常充电桩，包括：如果与所述充电桩相关的多个连续充电订单均为异常停止，且异常停止的原因均为充电桩故障，则确定所述充电桩为异常充电桩。
在一些实施例中，所述监控操作包括隔离操作，所述隔离操作包括：响应于从客户端获取充电请求，如果所述充电请求所请求的充电桩为所述异常充电桩，则向所述客户端返回所述异常充电桩异常的信息，和/或向所述客户端提供异常充电桩以外的其它正常充电桩的引导信息。
在一些实施例中，所述监控操作包括修复操作，所述修复操作包括：确定所述异常充电桩的版本是否为最新可用版本。
在一些实施例中，所述修复操作进一步包括：响应于确定所述异常充电桩的版本为最新可用版本，则向所述异常充电桩发送重启指令。
在一些实施例中，所述修复操作进一步包括：响应于确定所述异常充电桩的版本不是最新可用版本，则向所述异常充电桩发送升级指令。
在一些实施例中，在执行所述修复操作后，如果在预设时间段内仍然接收到所述异常充电桩发送的异常订单的信息，且异常原因为充电桩故障，则向相应处理人员的终端发送关于所述异常充电桩的维护工单。
在一些实施例中，在执行所述修复操作后，如果在预设时间段内未接收到所述异常充电桩发送的异常订单信息，则将所述异常充电桩设置为正常充电桩。
本申请的第五个方面涉及一种充电桩故障识别的***。所述***包括：一个或以上存储设备，存储用于充电桩故障识别的一组指令；以及所述一个或以上存储设备通信的一个或以上处理器，其中，当执行所述一组指令时，所述一个或以上处理器用于：响应于获取充电请求，对所述充电请求生成订单；在对车辆执行当前充电操作过程中，获取充电状态数据；确定所述充电状态数据中是否包括异常状态数据；响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符；以及发送所述异常订单至与所述充电桩连接的服务器。
本申请的第六个方面涉及一种充电桩故障识别和监控的***。所述***包括： 一个或以上存储设备，存储用于充电桩故障识别和监控的一组指令；以及与所述一个或以上存储设备通信的一个或以上处理器，其中，当执行所述一组指令时，所述一个或以上处理器用于：获取异常订单的信息，所述异常订单反映充电桩进行充电操作时存在异常状态数据的情况，所述异常订单的信息中包括与所述异常状态数据对应的标识符；以及根据所述标识符，确定所述异常订单的异常原因。
本申请的第七个方面涉及一种充电桩故障识别的***。所述***包括：一个或以上存储设备，存储用于充电桩故障识别和监控的一组指令；以及与所述一个或以上存储设备通信的一个或以上处理器，其中，当执行所述一组指令时，所述一个或以上处理器用于：获取服务器接收当前通讯数据的时间点，所述通讯数据由充电桩发送；以所述时间点为起点，确定在预设第一时间阈值内所述服务器是否接收到新的通讯数据；以及响应于确定在预设第一时间阈值内所述服务器没有接收到新的通讯数据，则确定所述充电桩存在离线故障点。
本申请的第八个方面涉及一种充电桩故障识别和监控的***。所述***包括：一个或以上存储设备，存储用于充电桩故障识别和监控的一组指令；以及与所述一个或以上存储设备通信的一个或以上处理器，其中，当执行所述一组指令时，所述一个或以上处理器用于：获取充电订单的信息，并对充电订单的信息进行分析；如果所述充电订单是异常停止，且异常停止的原因是充电桩异常导致的，则确定所述充电桩为异常充电桩；以及对所述充电桩进行监控操作。
本申请的第九个方面涉及一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现充电桩故障识别的方法，所述方法包括：响应于获取充电请求，对所述充电请求生成订单；在对车辆执行当前充电操作过程中，获取充电状态数据；确定所述充电状态数据中是否包括异常状态数据；响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符；以及发送所述异常订单至与所述充电桩连接的服务器。
本申请的第十个方面涉及一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现充电桩故障识别和监控的方法，所述方法包括：获取异常订单的信息，所述异常订单反映充电桩进行充电操作时存在异常状态数据的情况，所述异常订单的信息中包括与所述异常状态数据对应的标识符；以及根据所述标识符，确定所述异常订单的异常原因。
本申请的第十一个方面涉及一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现充电桩故障识别的方法，所述方法包括：获取服务器接收当前通讯数据的时间点，所述通讯数据由充电桩发送；以所述时间点为起点，确定在预设第一时间阈值内所述服务器是否接收到新的通讯数据；以及响应于确定在预设第一时间阈值内所述服务器没有接收到新的通讯数据，则确定所述充电桩存在离线故障点。
本申请的第十二个方面涉及一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现充电桩故障识别和监控的方法，所述方法包括：获取充电订单的信息，并对充电订单的信息进行分析；如果所述充电订单是异常停止，且异常停止的原因是充电桩异常导致的，则确定所述充电桩为异常充电桩；以及对所述充电桩进行监控操作。
本申请的一部分附加特性可以在下面的描述中进行说明。通过对以下描述和相应附图的研究或者对实施例的生产或操作的了解，本申请的一部分附加特性对于本领域技术人员是明显的。本申请的特征可以通过对以下描述的具体实施例的各种方面的方法、手段和组合的实践或使用得以实现和达到。
附图说明
本申请通过示例性实施例进行进一步描述。这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，各图中相同的编号表示相似的结构，其中：
图1是根据本申请的一些实施例所示的示例性充电监控***的示意图；
图2是根据本申请的一些实施例所示的可以在其上实现客户终端的示例性移动设备的示例性硬件和/或软件组件的示意图；
图3是根据本申请的一些实施所示的示例性计算设备的示例性硬件和软件组件的示意图；
图4是根据本申请的一些实施例所示的充电桩的示例性模块图；
图5是根据本申请的一些实施例所示的处理设备的示例性模块图；
图6是根据本申请的一些实施例所示的识别充电桩故障的示例性流程600的流程图；
图7是根据本申请的一些实施例所示的确定异常订单的异常原因的示例性流程 700的流程图；
图8是根据本申请的一些实施例所示的监控充电桩的示例性流程800的流程图；
图9是根据本申请的一些实施例所示的监控充电桩的示例性流程900的流程图；
图10是根据本申请的一些实施例所示的充电桩监控方法的示例性流程1000流程图；
图11是根据本申请的一些实施例所示的识别充电桩故障的示例性流程1100的流程图；
图12是根据本申请的一些实施例所示的识别充电桩故障的示例性流程1200的流程图；
图13是根据本申请的一些实施例所示的识别充电桩故障的示例性流程1300的流程图；
图14是根据本申请的一些实施例所示的示例性充电监控***的示意图；
图15A是根据本申请的一些实施例所示的充电桩与平台服务器之间的数据传输过程的示例性示意图；
图15B是根据本申请的一些实施例所示的充电桩与平台服务器之间的账单传输过程的示例性示意图；以及
图15C是根据本申请的一些实施例所示的充电桩与平台服务器之间的信号传输过程的示例性示意图。
具体实施方式
以下描述是为了使本领域的普通技术人员能够实施和利用本申请，并且该描述是在特定的应用场景及其要求的环境下提供的。对于本领域的普通技术人员来讲，显然可以对所公开的实施例做出各种改变，并且在不偏离本申请的原则和范围的情况下，本申请中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本申请并不限于所描述的实施例，而应该被给予与权利要求一致的最广泛的范围。
本申请中所使用的术语仅用于描述特定的示例性实施例，并不限制本申请的范围。如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可以包括复数。应当理解的是，本申请中所使用的术语“包括”和/或“包含”仅提示已明确标识的特征、步骤、操作、元素和/或部件，但并不排除可以存在或添加一个或以上其他特征、步骤、操作、元素、部件和/或其组合。
虽然本申请对根据本申请实施例的***中的某些模块做出了各种引用，然而，任何数量的不同模块可以被使用并运行在客户端、充电桩和/或服务器上。这些模块旨在说明，而不是为了限制本申请的范围。可以在本***和方法的不同方面使用不同的模块。
根据对以下附图的描述，本申请的特征以及相关结构元件的操作方法和功能，以及部件的组合和制造的经济性，可以变得更加显而易见，这些附图都构成本申请说明书的一部分。应当理解的是，附图仅仅是为了说明和描述的目的，并不旨在限制本申请的范围。应当理解的是，附图并不是按比例绘制的。
本申请中使用了流程图来说明根据本申请的一些实施例的***所执行的操作。应当理解的是，流程图中的操作可以不按顺序执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将一个或以上其他操作添加到这些流程图中，或从这些流程图中删除某一步或数步操作。
本申请中的术语“请求者”、“服务请求者”、“客户”、“用户”和“司机”可互换使用，其是指请求或订购服务的个人或实体。在本申请中，术语“司机”、“司机终端”、“用户设备”和“客户终端”可以互换使用。在本申请中，术语“服务请求”表示可以由用户(例如，乘客、请求者、操作员、服务请求者、客户、司机)发起的请求。例如，服务请求可以涉及使用充电桩对电动车辆充电。该***可以在许多领域中找到应用程序，例如，出租车运输服务、驾驶应用程序、地图应用程序或导航应用程序等。
在使用充电桩对车辆进行充电的过程中，一般会涉及3个参与方：用户、充电桩、车辆。异常订单的产生，可能是任意参与方造成的。例如，用户在启动充电后未连接好充电枪或者在充电过程中强制拔掉充电枪导致的订单异常；又例如，充电过程中，充电桩与车辆交互时车辆电池管理***未及时响应，充电桩强制结束订单导致的订单异常；又例如，充电桩本身存在故障也会引起的订单异常，如充电桩与服务器网络通信故障或充电枪连接装置松动等。在现有技术中，针对异常订单，通常将异常原因全部归结为充电桩故障，之后会派遣维修人员对充电桩进行故障维修。但是，有的情况下，充电桩的状态是正常的，这样的处理方式，往往导致维修人员在对充电桩进行检测后，并未发现问题，对人力物力等资源造成了浪费也依然没有解决问题。
此外，在一些情况下的充电桩监控报警方式，主要是充电桩和平台通信，让充电桩主动上报故障并诊断，但是如果充电桩本身异常没有主动上传故障异常信息，那么平台就无法及时的感知到故障。同时，即使充电桩在上传信息的时刻是正常的，也无法 完全保证桩在充电的时候没有异常故障问题。现有检测充电桩异常的方式，往往是人工发现的，这意味着，往往是用户反馈设备异常后，相关的维修人员才会赶到现场，进行维修操作。从故障到修复，存在着很大的延时。并且某些充电桩的故障可能属于“隐性故障”，比如，充电枪连接松弛，导致充电过程中经常出现订单异常。这类问题往往无法通过表面现象直观的观察到，比较难以发现。
针对上述问题，本申请的一些实施例提供了用于对充电桩进行自动故障识别和监控的***和方法。
本申请的一个方面涉及充电桩故障识别的***和方法。所述***和方法可以应用在充电桩端。充电桩可以响应充电请求，生成订单。充电桩可以在对车辆执行充电操作的过程中，获取充电状态数据，并确定充电状态数据中是否包括异常状态数据。充电桩可以基于异常状态数据确定异常订单，并对异常订单生成与异常状态数据对应的标识符。充电桩可以发送所述异常订单至与充电桩连接的服务器。根据本申请一些实施例，充电桩在为车辆充电过程中，可以对充电状态数据进行实时采集，根据充电状态数据能确定导致充电订单异常的原因，对不同原因引起的订单异常，配置不同的标识符。因此，当服务器接收到异常订单信息后，能够根据标识符确定订单异常原因。
本申请的另一个方面涉及充电桩故障识别和监控的***和方法。所述***和方法可以应用在与充电桩连接的服务器(例如，充电桩运营商平台服务器)。服务器可以获取异常订单的信息，并根据异常订单信息中的标识符，确定异常订单的异常原因。根据本申请一些实施例，服务器可以从订单信息中获取异常信息而非从设备中获取异常信息，能够更加准确地确定引起订单异常的实际原因，从而可以提高后续故障处理的效率，而对于不属于充电桩故障引起的原因也不必再派遣维修人员到现场对充电桩进行检修，因此能够避免资源浪费。此外，可以对出现故障的充电桩进行自动隔离及修复操作，进而提高了充电桩的运行效率。
本申请的另一个方面涉及充电桩故障识别的***和方法。所述***和方法可以应用在与充电桩连接的服务器(例如，充电桩运营商平台服务器)。服务器可以获取服务器接收当前通讯数据的时间点。服务器可以以所述时间点为起点，确定在预设第一时间阈值内所述服务器是否接收到新的通讯数据。响应于确定在预设第一时间阈值内所述服务器没有接收到新的通讯数据，则服务器可以确定所述充电桩存在离线故障点。根据本申请的一些实施例，可以对充电桩是否存在离线故障点进行自动识别，不但能够及时发现、预防充电桩的离线故障，同时能提高充电桩故障识别的全面性和准确性。
图1是根据本申请的一些实施例所示的示例性充电监控***的示意图。例如，充电监控***100(简称为***100)可以应用于线上到线下服务平台，例如运输服务平台。示例性的运输服务可以包括出租车呼叫服务、代驾服务、快车服务、拼车服务、公共汽车服务、司机租赁服务和班车服务等。***100可以包括服务器110、网络120、一个或以上客户终端130、一个或以上电动车辆140、存储设备150和包括一个或以上充电桩160的充电站170。应当注意，***100仅仅是一个示例，并不是限制性的。
在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。所述服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式的***)。在一些实施例中，服务器110可以是本地的，也可以是远程的。例如，服务器110可以经由网络120访问存储在客户终端130和/或存储设备150中的信息和/或数据。又例如，服务器110可以直接连接到客户终端130、存储设备150和/或充电桩160，以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实施。仅作为示例，云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。在一些实施例中，服务器110可以在本申请中的图3所示的包含了一个或以上组件的计算设备300上执行。在一些实施例中，服务器110可以是充电桩运营商服务平台。
在一些实施例中，服务器110可以包括一个或以上处理设备112。处理设备112可以处理与充电请求、充电桩故障识别、充电桩监控有关的信息和/或数据，以执行本申请中描述的一个或以上功能。例如，处理设备112可以获取异常订单的信息。处理设备112可以获取异常订单中与异常状态数据对应的标识符。处理设备112可以基于标识符确定异常订单的异常原因。又例如，处理设备112可以对异常充电桩进行监控操作。又例如，处理设备112可以获取当前通讯数据的时间点，所述通讯数据由充电桩160发送。处理设备112可以以当前通讯数据的时间点为起点，确定在预设第一时间阈值内是否接收到新的通讯数据。处理设备112可以响应于确定在预设第一时间阈值内没有接收到新的通讯数据，则确定充电桩存在离线故障点。
在一些实施例中，处理设备112可以包括一个或以上处理引擎(例如，单芯片处理引擎或多芯片处理引擎)。仅作为示例，处理设备112可包括中央处理器(CPU)、专用集成电路(ASIC)、专用指令处理器(ASIP)、图像处理器(GPU)、物理处理器(PPU)、数字信号处理器(DSP)、现场可编程门阵列(FPGA)、可编程逻辑电路(PLD)、控制器、微控制器单元、精简指令集电脑(RISC)、微处理器等或其任意组 合。
网络120可以促进信息和/或数据的交换。在一些实施例中，***100中的一个或以上组件(例如，服务器110、客户终端130、存储设备150、充电桩160)可以通过网络120将信息和/数据发送到***100中的其他组件。例如，服务器110可以经由网络120从客户终端130或充电桩160获取服务请求(例如，充电请求)。又例如，充电桩160可以将充电订单信息或充电状态数据经由网络120发送至服务器110。在一些实施例中，网络120可以是任何类型的有线或无线网络等或其任意组合。仅作为示例，网络120可以包括电缆网络、有线网络、光纤网络、电信网络、内部网络、互联网、局域网络(LAN)、广域网路(WAN)、无线局域网络(WLAN)、城域网(MAN)、公共交换电话网络(PSTN)、蓝牙网络、ZigBee网络、近场通信(NFC)网络等或其任意组合。在一些实施例中，网络120可以包括一个或以上网络接入点。例如，网络120可以包括有线或无线网络接入点，例如，基站和/或互联网交换点120-1、120-2、......，通过***100的一个或以上组件可连接到网络120以交换数据和/或信息。
在一些实施例中，客户终端130可以包括移动设备130-1、平板计算机130-2、膝上型计算机130-3、机动车辆内置设备130-4等或其任意组合。在一些实施例中，客户终端130可以促进处理设备112与客户终端130相关联的用户之间的通信和/或交互。例如，客户终端130可以基于用户经由用户界面的输入生成充电请求。处理设备112可以从客户终端130接收充电请求。又例如，处理设备112可以将一个或以上充电站和/或充电桩有关的信息发送到客户终端130以显示给用户。
在一些实施例中，移动设备130-1可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、增强现实设备等或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器控制装置、智能监控设备、智能电视、智能摄像机、对讲机等或其任意组合。在一些实施例中，该可穿戴设备可包括智能手环、智能鞋袜、智能眼镜、智能头盔、智能手表、智能服装、智能背包、智能配件等或其任意组合。在一些实施例中，智能移动设备可以包括智能电话、个人数字助理(PDA)、游戏设备、导航设备、销售点(POS)等或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实眼镜、虚拟现实眼罩、增强现实头盔、增强现实眼镜、增强现实眼罩等或其任意组合。例如，虚拟现实设备和/或增强现实设备可包括Google Glass、Oculus Rift、HoloLens或GearVR等。在一些实施例中，机动车辆内置设备130-4可以包括车载计算机或车载电视等。在一些实施例中，客户终端130可以 是具有定位技术的设备，用于定位服务请求者和/或客户终端130的位置。
一个或以上电动车辆140可以包括一个或以上的电动汽车(例如，电动汽车140-1、电动汽车140-2等)、一个或以上电动摩托140-3、一个或以上电动自行车140-4等，或其组合。电动车辆140可包括用于与其他电动车辆区分的标识。电动车辆140的标识可以包括车辆信息，例如车辆类型、车辆品牌、车辆牌照号码、车辆编号等，或其组合。
存储设备150可以储存数据和/或指令。在一些实施例中，存储设备150可以存储从客户终端130获取的数据。例如，存储设备150可以存储来自客户终端130的对电动车辆140的充电请求。又例如，存储设备150可以存储与电动车辆140有关的信息。又例如，存储设备150可以存储与充电桩160有关的信息。又例如，存储设备150可以存储与充电过程有关的信息(例如，充电状态数据)。在一些实施例中，存储设备150可以储存服务器110用来执行或使用来完成本申请中描述的示例性方法的数据和/或指令。在一些实施例中，存储设备150可以包括大容量存储器、可移动存储器、易失性读写存储器、只读存储器(ROM)等或其任意组合。示例性大容量存储器可以包括磁盘、光盘、固态驱动器等。示例性可移动存储器可以包括闪存驱动器、软盘、光盘、存储器卡、压缩盘、磁带等。示例性易失性读写存储器可以包括随机存取存储器(RAM)。示例性RAM可包括动态随机存取存储器(DRAM)、双倍数据速率同步动态随机存取存储器(DDRSDRAM)、静态随机存取存储器(SRAM)、晶闸管随机存取存储器(T-RAM)和零电容随机存取存储器(Z-RAM)等。示例性只读存储器可以包括掩模型只读存储器(MROM)、可编程只读存储器(PROM)、可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、光盘只读存储器(CD-ROM)和数字多功能磁盘只读存储器等。在一些实施例中，所述存储设备150可在云平台上实现。仅作为示例，云平台可以包括私有云、公共云、混合云、社区云、分布云、内部云、多层云等或其任意组合。
在一些实施例中，存储设备150可以连接到网络120以与***100中的一个或以上组件(例如，服务器110、客户终端130、充电桩160、电动车辆140)通信。***100中的一个或以上组件可以经由网络120访问存储在存储设备150中的数据和/或指令。在一些实施例中，存储设备150可以直接连接到***100中的一个或以上组件(例如，服务器110、客户终端130、充电桩160、电动车辆140)或与之通信。在一些实施例中，存储设备150可以是服务器110、客户终端130、充电桩160或电动车辆140的一部分。
充电站170可包括一个或以上充电桩160。充电桩160被配置为对电动车辆(例如，电动车辆140)充电。在一些实施例中，充电桩160可以包括提供电力的电源设备、连接至电动车辆的充电接口、用于存储充电过程中产生的数据的存储器、控制器(例如，图4所示的控制器400)、一个或以上传感器等或其任何组合。充电桩160还可以进一步包括一个或以上可操作部件，例如，桩体、充电枪、柜门、急停按钮等或其任何组合。
在一些实施例中，控制器可以包括获取模块(例如，图4所示的获取模块410)、生成模块(例如，图4所示的生成模块420)、确定模块(例如，图4所示的确定模块430)和控制模块(例如，图4所示的控制模块440)等。关于控制器的更多描述可以在本申请的其它地方(例如，图4及其描述)找到。
传感器用于检测充电桩的实际状态数据。传感器可以包括温度传感器、电流传感器、电压传感器、压力传感器等或其任何组合。温度传感器用于检测充电桩的部件(例如，桩体)的实时温度。电流传感器用于检测流过充电桩的部件(例如，充电枪)的实时电流值。电压传感器用于检测充电桩的部件(例如，充电枪端头)的实时电压值。压力传感器用于检测充电桩的部件之间(例如，充电枪端头与充电桩桩体之间)的压力值。
以上关于***100的描述旨在是说明性的，而不是限制本申请的范围。对于本领域技术人员而言，许多替代、修改和变化将是显而易见的。本申请描述的示例性实施例的特征、结构、方法和其它特征可以以各种方式组合以获取另外的和/或替代的示例性实施例。然而，这些变化和修改不脱离本申请的范围。例如，客户终端130可以省略，用户可以直接在充电桩160上发起充电请求。
图2是根据本申请的一些实施例所示的可以在其上实现客户终端的示例性移动设备的示例性硬件和/或软件组件的示意图。移动设备200可以包括一个或以***处理单元(CPU)240、一个或以上图形处理单元(GPU)230、显示器220、内存260、通信单元210、存储单元290，以及一个或以上输入/输出(I/O)设备250。此外，移动设备200还可以包括但不限于***总线或控制器(图2中未示出)的任何其他合适的组件。如图2所示，移动操作***270(例如，IOS、Android、Windows Phone等)和一个或以上应用程序280可以从存储单元290加载到内存260中，以便由CPU 240执行。应用程序280可以包括浏览器或其他移动应用程序，用于接收和处理与用户在移动设备200中输入的与充电有关的信息。用户可以通过***I/O设备250获取与一个或以上与充电有关的信息，并将该信息提供给服务器110和/或***100的其他模块或单元。
图3是根据本申请的一些实施所示的示例性计算设备的示例性硬件和软件组件 的示意图。可以在计算设备300上实现服务器110、客户终端130或充电桩160的功能。计算设备300可以被配置为执行本申请中公开的服务器110、客户终端130和充电桩160的一个或以上功能。例如，处理设备112可以在计算设备300上实现并被配置为执行本申请中公开的处理设备112的功能。
计算设备300可以是通用计算机或专用计算机，两者都可以用于实现本申请的***100。计算设备300可用于实现如本申请所述的***100的任何组件。例如，处理设备112可以通过其硬件、软件程序、固件或其组合在计算设备300上实现。为了方便起见，图中仅示出了一台计算机，但是本申请描述的与充电服务有关的计算机功能可以在多个类似平台上以分布式方式实现，以分散处理负载。
例如，计算设备300可以包括通信端口350，其连接于网络和/或来自于网络，以实现数据通信。计算设备300还可以包括一个或以上处理器形式的处理器320，用来执行程序指令。示例性的计算机平台可以包括内部通信总线310、不同类型的程序存储器和数据存储器(例如，磁盘370、只读存储器(ROM)330或随机存取存储器(RAM)340)、由计算机处理和/或传输的各种数据文件。示例性的计算机平台还包括存储在ROM 330、RAM 340和/或其他形式的非暂时性存储介质中的由处理器320执行的程序指令。本申请的方法和/或流程可以以程序指令的方式实现。计算设备300还可以包括输入/输出设备360，其可以支持计算机和其他组件之间进行输入/输出。计算设备300也可以通过网络通信接收编程和数据。
计算设备300还可以包括与硬盘通信的硬盘控制器、与小键盘/键盘通信的小键盘/键盘控制器、与串行接口设备通信的串行接口控制器、与并行接口设备通信的并行接口控制器、与显示器通信的显示控制器等或其任意组合。
仅仅为了说明，计算设备300中仅示例性描述了一个CPU和/或处理器。然而，需要注意的是，本申请中的计算设备300可以包括多个CPU和/或处理器，因此本申请中描述的由一个CPU和/或处理器实现的操作和/或方法也可以由多个CPU和/或处理器共同地或独立地实现。例如，如果在本申请中，计算设备300的CPU和/或处理器执行操作A和操作B，应当理解，操作A和操作B也可以由计算设备300中的两个不同的CPU和/或处理器联合地或独立地执行(例如，第一处理器执行操作A、第二处理器执行操作B，或者第一和第二处理器共同执行操作A和操作B)。
图4是根据本申请的一些实施例所示的充电桩的示例性模块图。充电桩160可以包括控制器400，控制器400可以包括获取模块410、生成模块420、确定模块430和 控制模块440。
获取模块410可以获取数据或信息。获取模块410可以从***100的一个或以上组件(例如，客户终端130、电动车辆140、存储设备150)或外部设备(例如，云数据库)获取数据/信号。仅作为示例，所获取的数据/信号可以包括充电请求、充电状态数据等或其任意组合。在一些实施例中，在充电桩对车辆执行当前充电操作过程中，获取模块410可以获取充电状态数据。关于获取充电状态数据的更多描述可以在本申请的其它地方(例如，图6及其相关描述)找到。
生成模块420可以生成数据或信息。在一些实施例中，生成模块420可以基于充电请求生成订单。例如，响应于获取充电请求，生成模块420可以对所述充电请求生成充电订单。关于生成充电订单的更多描述可以在本申请的其它地方(例如，图6及其相关描述)找到。
确定模块430可以确定数据或信息。在一些实施例中，确定模块430可以确定充电状态数据中是否包括异常状态数据。异常状态数据可以包括充电桩的可操作部件的异常状态数据、充电桩与车辆之间的异常交互数据等。充电桩的可操作部件的异常状态数据可以包括充电枪被异常拔出、充电柜门被异常打开、急停按钮被异常按下等。充电桩与车辆之间的异常交互数据可以包括充电桩与被充电车辆之间的通信连接异常(例如，连接超时、连接失败)、被充电车辆向充电桩反馈的车辆当前电量数据异常等。在一些实施例中，响应于确定充电状态数据中包括异常状态数据，确定模块430可以确定订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符。关于确定充电状态数据中是否包括异常状态数据和对异常订单生成与异常状态数据对应的标识符的更多描述可以在本申请的其它地方(例如，图6及其相关描述)找到。
控制模块440可以发送数据或信息。在一些实施例中，控制模块440可以发送异常订单至与充电桩连接的服务器。例如，控制模块440可以将异常订单和标识符发送至与充电桩160连接的服务器110。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。例如，生成模块420和确定模块430可以集成为一个模块。
图5是根据本申请的一些实施例所示的处理设备的示例性模块图。处理设备112可以包括获取模块510、确定模块520和控制模块530。
获取模块510可以获取数据或信息。获取模块510可以从***100的一个或以上组件(例如，客户终端130、电动车辆140、存储设备150、充电桩160)或外部设备(例如，云数据库)获取数据/信号。例如，获取模块510可以获取异常订单的信息，异常订单信息可以反映充电桩进行充电操作时存在异常状态数据的情况，异常订单的信息中可以包括与异常状态数据对应的标识符。又例如，获取模块510可以获取订单的信息并对所述订单的信息进行分析。又例如，获取模块510可以获取服务器接收当前通讯数据的时间点，通讯数据由充电桩发送。又例如，获取模块510可以获取充电桩的历史异常订单数量和历史订单总数量。又例如，获取模块510可以获取充电桩的状态数据。又例如，获取模块510可以获取充电站中被确定为存在故障的充电桩占充电桩总数的比例。
确定模块520可以确定数据或信息。例如，确定模块520可以根据异常订单的标识符，确定异常订单的异常原因。又例如，若订单为异常订单，且异常订单的异常原因为充电桩故障，确定模块520可以确定与所述异常订单对应的充电桩为异常充电桩。又例如，如果与充电桩相关的多个连续订单均为异常停止，且异常停止的原因均为充电桩故障，确定模块520可以确定所述充电桩为异常充电桩。又例如，确定模块520可以以所述时间点为起点，确定在预设第一时间阈值内服务器是否收到新的通讯数据。又例如，确定模块520可以，响应于确定在预设第一时间阈值内服务器没有接收到新的通讯数据，确定充电桩存在离线故障点。又例如，确定模块520可以，响应于确定在预设第一时间阈值内服务器没有接收到新的通讯数据，且充电状态数据中包括订单异常信息，则对异常订单生成订单异常标识符。又例如，确定模块520可以确定充电桩的历史异常订单数量占历史订单总数量的比例是否超过比例阈值。响应于确定所述充电桩的历史异常订单数量占历史订单总数量的比例超过所述比例阈值，确定模块520可以确定所述充电桩存在故障。响应于确定所述充电桩的历史异常订单数量占历史订单总数量的比例不超过所述比例阈值，确定模块520可以确定所述充电桩不存在故障。又例如，确定模块520可以确定充电桩的状态数据是否在预设范围内。响应于确定所述充电桩的状态数据不在所述预设范围内，确定模块520可以确定所述充电桩存在故障。又例如，确定模块520可以确定充电站中被确定为存在故障的充电桩占充电桩总数的比例是否超过阈值。响应于确定所述比例超过所述阈值，确定模块520可以获取所述充电站的站点属性以及与所述站点属性对应的第二终端属性。
控制模块530可以发送数据或信息。在一些实施例中，控制模块530可以对异 常充电桩进行监控操作。又例如，控制模块530可以对异常充电桩进行隔离操作。又例如，控制模块530可以对异常充电桩进行修复操作。在一些实施例中，在执行修复操作之后，控制模块530可以将异常充电桩设置为正常充电桩。在一些实施例中，控制模块530可以向处理人员的终端发送提醒信息。例如，控制模块530可以向相应处理人员的终端发送关于异常充电桩的维护工单。又例如，控制模块530可以根据第一终端属性发送故障提醒信息至第一终端，故障提醒信息包括充电桩的设备属性。又例如，控制模块530可以根据所述第二终端属性发送报警信息至第二终端，所述报警信息包括所述充电站的站点属性。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。例如，获取模块510和确定模块520可以集成为一个模块。
图6是根据本申请的一些实施例所示的识别充电桩故障的示例性流程600的流程图。流程600可以由***100执行。在一些实施例中，图6所示的流程600的一个或以上操作可以在图1所示的***100中实现。例如，图6所示的流程600可以以指令的形式存储在存储设备中，并由充电桩调用和/或执行。以下所示流程的操作仅出于说明的目的。在一些实施例中，流程600可以包括一个或以上未描述的附加操作和/或一个或以上没有讨论的操作。另外，图6所示和下面描述的流程的操作顺序不是限制性的。
在610中，响应于获取充电请求，对所述充电请求生成订单。该步骤可以由充电桩160(例如，生成模块420)执行。
在一些实施例中，充电请求可以是用户基于电动车辆电量不足或缺失而发起的服务需求。充电请求可以包括与待充电的电动车辆有关的车辆信息。与电动车辆有关的车辆信息可以包括电动车辆的车牌号、电动车辆的型号、电动车辆的当前电量、电动车辆的充电器的型号等或其任何组合。
在一些实施例中，用户(例如，司机)可以通过客户终端(例如，客户终端130)发起充电请求，充电桩可以从客户终端接收充电请求。例如，用户可以通过客户终端的用户界面(例如，应用程序)发起充电请求。又例如，用户可以通过使用客户终端扫描充电桩头的充电码发起充电请求。在一些实施例中，用户可以直接通过充电桩发起充电请求。例如，当电动车辆连接到充电桩时，充电桩可以自动生成充电请求。又例如，充电桩可以包括操作界面，用户可以通过充电桩的操作界面发起充电请求。
在一些实施例中，充电桩可以基于充电请求生成充电订单。可替代地，充电请求可以被发送至服务器(例如，处理设备112)，服务器可以根据用户的充电请求向充电桩发送充电启动信号，同时为当前充电操作分配一个充电订单。订单信息可以包括用户的信息(例如，身份信息、用户历史充电请求、用户历史充电记录、用户当前地理位置)、电动车辆的信息(例如，车辆型号、车牌号、历史充电记录、充满电所需电量、当前电量)、充电桩的信息(例如，充电桩编号、充电状态数据、充电桩充电功率、充电桩累计充电电量、充电桩历史维修记录)等或其任何组合。在一些实施例中，订单信息可以包括用户注册时预留的信息(例如，用户终端信息、充电车辆的信息)或实时获取的信息(例如，充电桩的信息)。
在620中，在对车辆执行当前充电操作过程中，获取充电状态数据。该步骤可以由充电桩160(例如，获取模块410)执行。
在一些实施例中，在充电桩对车辆执行充电操作的过程中，充电桩可以获取充电状态数据。充电状态数据可以包括充电桩的状态数据(例如，充电桩可操作部件的状态数据)、充电桩与车辆之间的交互数据、充电开启或结束时发送的提醒信号、充电过程中与充电量计算相关的信号、充电结束后发送的账单数据等或其任意组合。如本申请所使用的，可操作部件可以指能被人为操作的部件。例如充电桩的可操作部件可以包括桩体、充电枪、充电桩柜门、充电桩急停按钮等。充电桩可操作部件的状态数据可以包括充电桩的可操作部件的温度、电流值、电压值、充电桩的实时输出功率、充电桩的累计充电时长、充电桩的累计充电量等。充电桩与车辆之间的交互数据可以包括充电桩与被充电车辆之间的通信连接状态、被充电车辆向充电桩反馈的车辆当前电量数据等。
在一些实施例中，充电桩可以利用其内部安装的传感器、通信模块等实时检测充电状态数据、与被充电车辆进行数据通信以及与服务器进行数据通讯。例如，充电桩的传感器可以包括第一温度传感器、第二温度传感器、电流传感器、电压传感器、压力传感器等或其任何组合。第一温度传感器可以用于检测充电桩桩体的实时温度值作为桩体的实际状态数据并发送至充电桩的控制器。第二温度传感器可以用于检测充电枪的实时温度值并发送至控制器。电流传感器可以用于检测流过充电枪的实时电流值并发送至控制器。电压传感器可以用于检测充电枪端头的实时电压值并发送至控制器。压力传感器可以用于检测充电枪端头与充电桩桩体之间的压力值并发送至控制器。
在630中，确定所述充电状态数据中是否包括异常状态数据。该步骤可以由充电桩160(例如，确定模块430)执行。
在执行充电操作的过程中，参与充电的有充电桩、用户和被充电车辆等，任何一方出现充电异常行为(例如，用户操作异常、充电桩故障、被充电车辆故障)都可能导致异常状态数据的出现。异常状态数据可以包括充电桩的可操作部件的异常状态数据、充电桩与车辆之间的异常交互数据等。充电桩的可操作部件的异常状态数据可以包括充电枪被异常拔出、充电柜门被异常打开、急停按钮被异常按下等。充电桩与车辆之间的异常交互数据可以包括充电桩与被充电车辆之间的通信连接异常(例如，连接超时、连接失败)、被充电车辆向充电桩反馈的车辆当前电量数据异常等。
在一些实施例中，充电桩(例如，充电桩的存储设备)中可以预先存储充电桩的充电状态数据的标准范围(例如，标准状态数据表)。充电桩的充电状态数据的标准范围是指充电桩在正常工作状态下的充电状态数据的标准范围。例如，标准状态数据表可以包括桩体温度的标准范围、充电枪端头电流的标准范围、充电枪端头的电压的标准范围等。当充电桩的控制器接收到传感器发送的实际状态数据之后，可以根据标准状态数据表中记录的标准状态数据对传感器发送的实际状态数据进行比对检验，从而确定传感器所对应部件是否存在故障。
例如，充电桩可以包括对充电枪的电流进行检测的传感器，正常情况下，响应到启动充电信号后，如果用户正常将充电桩***被充电车辆且连接成功，充电枪的电流值会发生变化，此时如果传感器检测到电流值没有按照正常情况变化，则可以认为用户没有成功连接充电枪。而充电枪在充电过程中，其电流变化也是有一定规律的，如果在充电时充电枪的电流值突变为零，则可以认为是充电枪断开了与车辆的连接，认为充电枪异常拔出。基于相似的原理，充电桩中的相应传感器可以检测充电柜门是否被异常打开、急停按钮是否被异常按下等。
又例如，充电桩可以获取被充电车辆的响应时间，若被充电车辆的响应时间超过设定阈值，则认为充电桩与被充电车辆之间的通讯连接异常。在一些实施例中，被充电车辆的响应时间通过如下方式获得：在执行当前充电操作的过程中，向被充电车辆发送充电信号；获取被充电车辆根据所述充电信号反馈的响应信号；所述响应信号的接收时间和所述充电信号的发送时间之间的间隔为所述被充电车辆的响应时间。
充电桩在充电过程中，需要和被充电车辆进行数据通信，获取被充电车辆的电池信息，从而根据电池信息调整充电速度、输出功率等。而如果此时充电桩无法与车辆成功通信，无法获取到车辆电池数据，则可能会导致订单无法继续，出现异常订单。相类似地，还可以对充电过程中被充电车辆的鉴权结果、继电器电压、电池管理***的通 讯功能、动力蓄电池的绝缘性和连接器功能等进行检测。
在640中，响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符。该步骤可以由充电桩160(例如，确定模块430)执行。
在一些实施例中，异常订单可以指由于异常状态数据导致充电操作未正常完成的订单。例如，由于充电枪连接装置损坏导致充电桩与车辆无法连接，则订单无法正常完成。在一些实施例中，异常订单也可以指，虽然充电状态数据中包括异常状态数据，但是充电操作仍可以正常完成的订单。例如，在车辆的充电过程中，充电桩与车辆之间的通讯中断一段时间，而后又恢复通讯，此时充电操作仍可以完成。
在一些实施例中，不同类型的充电状态数据异常导致的订单异常会被分配不同的标识符。例如，响应于确定所述充电桩可操作部件的状态数据为异常状态，则对所述异常订单生成第一标识符。即所述第一标识符表示由于可操作部件异常导致订单异常。又例如，响应于确定所述交互数据为异常状态，则对所述异常订单生成第二标识符。即所述第二标识符表示由于充电桩与被充电车辆的通信异常导致订单异常。标识符用于标识异常订单的类型。在一些实施例中，标识符可以是***数字、字母、文字、代码等或其任意组合。例如，标识符可以是字母A、B、C等。又例如，标识符可以是故障类型1、故障类型2、故障类型3等。
在一些实施例中，充电桩可以获取异常状态数据与标识符之间的映射关系，并根据映射关系和异常状态数据，确定异常订单的标识符。异常状态数据与标识符之间的映射关系可以是***100的组件(例如，处理设备112)确定的，并存储在***100的存储设备(例如，存储设备150)中，充电桩可以从存储设备中获取映射关系。例如，映射关系可以是充电桩服务器定义并下发的，根据服务器下发的映射关系确定标识符能够为准确定位到异常原因提供数据基础。
在一些实施例中，一个异常订单可以对应多个标识符。例如，如果某个订单对应的异常状态数据包括充电桩与被充电车辆之间的通信连接超时、充电枪异常拔出和急停按钮被异常按下，并且对应充电桩可操作部件的状态数据为异常状态的标识符设置为A，对应充电桩与车辆交互数据为异常状态的标识符设置为B，则充电桩可以确定所述订单是异常订单，并对所述异常订单生成标识符A+B。
根据本申请的一些实施例，能够为每一个异常订单信息分配标识符，不同标识符能够代表不同的异常原因，由此服务器在确定异常订单时就能够根据标识符快速定位 到异常原因。
在650中，发送所述异常订单至与所述充电桩连接的服务器。该步骤可以由充电桩160(例如，控制模块440)执行。
在一些实施例中，充电桩可以通过网络(例如，网络120)将包括标识符的异常订单发送至与充电桩连接的服务器(例如，服务器110)。服务器获取异常订单后，可以根据标识符，确定异常订单的异常原因。关于确定异常订单的异常原因的更多描述可以在本申请的其它地方(例如，图7及其相关描述)找到。
根据本申请的一些实施例，在充电桩为车辆充电的过程中，根据充电状态数据可以确定导致充电订单异常的原因，为不同原因引起的订单异常配置不同的标识符。因此，当服务器接收到异常订单信息后，能够根据标识符确定订单异常原因。通过本申请的一些实施例，能够确定引起订单异常的实际原因，从而可以提高后续故障处理的效率，而对于不属于充电桩故障引起的原因也不必再派遣维修人员到现场对充电桩进行检修，因此能够避免资源浪费。
应该注意的是，上述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。例如，操作620和操作630可以合并为一个操作。又例如，可以省略操作610，服务器可以基于充电请求生成充电订单，并将充电订单发送至充电桩。
图7是根据本申请的一些实施例所示的确定异常订单的异常原因的示例性流程700的流程图。流程700可以由***100执行。在一些实施例中，图7所示的流程700的一个或以上操作可以在图1所示的***100中实现。例如，图7所示的流程700可以以指令的形式存储在存储设备中，并由服务器110(例如，处理设备112)调用和/或执行。以下所示流程的操作仅出于说明的目的。在一些实施例中，流程700可以包括一个或以上未描述的附加操作和/或一个或以上没有讨论的操作。另外，图7所示和下面描述的流程的操作顺序不是限制性的。
在710中，获取异常订单的信息，异常订单信息反映充电桩进行充电操作时存在异常状态数据的情况，异常订单的信息中包括与异常状态数据对应的标识符。该步骤可以由处理设备112(例如，获取模块510)执行。
处理设备112可以与充电桩(例如，充电桩160)进行通信，从而从充电桩获取异常订单的信息。在一些实施例中，一旦充电桩确定异常订单，充电桩可以通过网络120 实时地向处理设备112发送异常订单的信息。在一些实施例中，处理设备112可以周期性地(例如，每天、每周、每月)从充电桩获取异常订单的信息。在一些实施例中，当充电桩确定的异常订单达到预设阈值时，处理设备112才从充电桩获取异常订单的信息。在一些实施例中，充电桩可以将异常订单的信息发送至***100的存储设备(例如，存储设备150)，处理设备112可以从存储设备中获取异常订单的信息。
异常订单信息可以反映充电桩进行充电操作时存在异常状态数据的情况。例如，异常订单的信息中可以包括与异常状态数据对应的标识符，即标识符可以表示异常状态的类型。关于异常状态数据和标识符的更多描述可以在本申请的其它地方(例如，图6及其相关描述)找到。
在720中，根据所述标识符，确定异常订单的异常原因。该步骤可以由处理设备112(例如，确定模块520)执行。
在一些实施例中，按照充电过程的参与方，可以将异常订单的异常原因分为包括但不限于如下3个种类：充电桩故障(桩责)、车辆故障(车责)和非正常操作(人责)。其中，充电桩故障(桩责)可以理解为由于充电桩故障导致的订单异常，例如网络模块故障、充电枪连接装置损坏、柜门无法正常关闭、急停按钮出现故障等。非正常操作(人责)可以理解为由于用户不正确操作导致的订单异常，例如未插枪启动充电、充电过程中拔枪、未按规定开柜门、违规按下急停按钮等。车辆故障(车责)可以理解为由于车辆与桩交互问题导致的订单异常，例如车辆未及时响应充电桩的电池信息查询、充电车辆上报的充电信息不准确等。
在一些实施例中，充电桩为异常订单分配了标识符，不同标识符可以表示不同的异常状态数据类型，根据不同的异常状态数据类型能够确定出是由于充电桩故障、车辆故障还是操作不当引起的异常订单。具体地，处理设备112可以获取与异常订单对应的充电桩信息。与异常订单对应的充电桩是指产生异常订单的充电桩，即异常订单中对车辆进行充电操作的充电桩。例如，处理设备可以从异常订单的信息中提取充电桩的信息(例如，充电桩的地理位置、充电桩的编号)。然后，处理设备112可以获取历史时间段内与充电桩信息对应的历史异常订单的信息，并获取历史异常订单的信息中的历史标识符。历史时间段可以是存储在存储设备(例如，存储设备150)中的默认值。附加地或替代地，历史时间段可以根据不同情况手动设置或由***100的一个或以上组件确定。例如，历史时间段可以是最近一周内、最近一个月内、最近三个月内等。例如，处理设备可以获取最近一周内与异常订单对应的充电桩产生的所有历史异常订单的信息， 并提取历史异常订单信息中的历史标识符。进一步地，处理设备112可以根据(与当前异常状态数据对应的)标识符在历史标识符中的所占比例确定异常订单的异常原因。
在一些实施例中，所述标识符为第一标识符，第一标识符可以指示所述充电桩的可操作部件的状态数据为异常状态。这类原因可能是用户操作不当，例如未成功连接充电枪、充电过程中拔枪、未按规定开柜门、违规按下急停按钮等，也可能是充电桩自身故障，例如充电枪端子松动导致无法正常连接、柜门无法正常关闭、急停按钮出现故障等。如果是充电桩自身故障，那么在历史时间段内该类原因引起的订单异常应该占有绝大比例(例如，接近甚至达到100％)，而如果是人为操作不当的话，该类原因引起的订单异常应该是偶发性因而所占比例应该很小。因此能够根据该类异常原因在历史订单中所占比例判断是充电桩故障还是人为非正常操作。
相应地，处理设备112可以确定所述第一标识符在所述历史标识符中的所占比例是否大于阈值。阈值可以是存储在存储设备(例如，存储设备150)中的默认参数。附加地或替代地，阈值可以根据不同情况手动设置或由***100的一个或以上组件确定。例如，阈值可以设置为90％。响应于确定所述第一标识符在所述历史标识符中的所占比例大于所述阈值，则确定所述异常原因为充电桩故障。响应于确定所述第一标识符在所述历史标识符中的所占比例小于所述阈值，则确定所述异常原因为非正常操作。
仅作为示例，假设处理设备112获取的某个异常订单的标识符为第一标识符，异常订单对应的充电桩是1号充电桩，处理设备112提取的1号充电桩在过去一周内产生的历史异常订单信息为：8次充电桩柜门异常关闭、10次充电枪被异常拔出和2次网络连接故障，相应地，处理设备112获取的历史异常订单信息中的历史标识符可以为：18个第一标识符和2个第二标识符，处理设备112确定第一标识符在历史标识符中的所占比例是90％(18/20＝90％)。假设阈值设置为85％，则处理设备112可以确定异常订单的异常原因为充电桩故障。
在一些实施例中，所述标识符为第二标识符，第二标识符指示所述充电桩与被充电的车辆之间的交互数据为异常状态。这类原因可能是充电桩故障也可能是被充电车辆故障。如果是充电桩自身故障，那么在历史时间段内该类原因引起的订单异常应该占有绝大比例(例如，接近甚至达到100％)，而如果是被充电车辆故障的话，该类原因引起的订单异常应该是偶发性因而所占比例应该很小。因此能够根据该类异常原因在历史订单中所占比例判断是充电桩故障还是车辆故障。
相应地，处理设备112可以确定所述第二标识符在所述历史标识符中的所占比 例是否大于阈值。响应于确定所述第二标识符在所述历史标识符中的所占比例大于所述阈值，则确定所述异常原因为充电桩故障。响应于确定所述第二标识符在所述历史标识符中的所占比例小于所述阈值，则确定所述异常原因为车辆故障。
根据本申请的一些实施例，服务器收到充电桩上报的异常订单信息后，根据预先定义的标识符，自动按照一定历史时间段(例如，一天、一周)以充电站、运营商等粒度，利用聚合算法对订单异常情况进行统计分析，从而确定异常原因所在。
在一些实施例中，处理设备112可以生成异常状态数据与标识符之间的映射关系，并发送所述映射关系至充电桩。由此能够确保充电桩上报的异常订单信息中的标识符与平台服务器定义的标识符具有统一的标准。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。在一些实施例中，流程700还可以包括生成异常原因与处理人员之间的映射关系，以及发送所述异常原因至相应处理人员的终端。例如，处理设备112可以根据预案信息确定与所述异常原因对应的终端，并发送所述异常原因至所述终端。所述预案信息可以记录异常原因、处理人员和处理人员的终端之间的对应关系。仅作为示例，处理设备112可以根据处理人员预留手机号将异常原因通过短信发送至处理人员。也就是说，服务器端可以针对异常原因，采取自动化消息推送措施，推动相关责任方跟进解决，进而降低订单异常率。
在一些实施例中，如果异常订单的异常原因为充电桩故障。服务器可以将充电桩故障推送给充电桩维修人员，这样可以将故障定位到具体的充电桩乃至充电枪，帮助维修人员快速对充电桩进行维修。如果经过统计后发现某个充电站的充电桩频繁产生异常订单，服务器可以将该充电站的充电桩故障推送给充电站负责人。更进一步，如果经过统计后发现某种品牌乃至某些批次的充电桩频繁产生异常订单，那么可以怀疑该批次的充电桩使用的模块存在缺陷，服务器可以自动产生告警消息，例如将充电桩故障反馈给充电桩品牌负责人，请求他们协助排查问题。
在一些实施例中，如果异常订单的异常原因为非正常操作，服务器可以将异常原因推送给用户，以帮助用户规范操作。由于不按照规定流程操作，会有很大的安全隐患，所以必须采用行之有效的手段约束用户。例如对于充电过程中擅自拔枪的行为，服务器可以通过APP将异常原因推送给用户，同时推送安全操作规范，或者禁用账号1天后要求用户签订安全操作手册等，帮助用户形成良好的安全观念，降低安全风险。
在一些实施例中，如果异常订单的异常原因为车辆故障(例如，由于车辆通讯模块未及时响应充电桩的请求导致的异常)，服务器可以将异常原因推送给用户，以提醒用户车辆可能出现故障。例如，通过聚合分析，一旦发现某个用户的车辆频繁出现这种情况，基本可以断定车辆的通讯模块发生故障。为了不影响用户的使用并保障用户的安全，服务器可以自动通过APP通知、短信等方式，告知用户，便于用户进行车辆的维修。
在一些实施例中，服务器在统计订单异常原因时，可以实施监控告警机制。例如，充电桩维修人员，可以根据自己的检修负责区域，订阅特定桩站的桩责异常订单统计，服务器需要提供这种消息订阅途径，例如，电子邮件、IM消息等，通过这种途径形成一种主动的问题发现、解决机制，打破以往的被动等待上报问题的窘境，进而可以提高设备的可用性。同时，充电站负责人，也可以通过订阅充电站订单汇总情况，对自己负责的场站设备的情况有总体的认知。
通过上述异常统计、通知机制，明确责任主体的情况，可以自动、快速、精确的定位异常根源，进而推动相关人员实施改进方案，可以大幅降低订单异常率，还可以附加的提高用户操作安全性。
图8是根据本申请的一些实施例所示的监控充电桩的示例性流程800的流程图。流程800可以由***100执行。在一些实施例中，图8所示的流程800的一个或以上操作可以在图1所示的***100中实现。例如，图8所示的流程800可以以指令的形式存储在存储设备中，并由服务器110(例如，处理设备112)调用和/或执行。以下所示流程的操作仅出于说明的目的。在一些实施例中，流程800可以包括一个或以上未描述的附加操作和/或一个或以上没有讨论的操作。另外，图8所示和下面描述的流程的操作顺序不是限制性的。
在810中，获取订单的信息并对所述订单的信息进行分析。该步骤可以由处理设备112(例如，获取模块510)执行。
在一些实施例中，充电桩可以与服务器(例如，处理设备112)进行通信，向服务器(例如，处理设备112)上传充电订单，并汇报停止充电的原因。例如，当用户使用充电桩充电时，可以通过客户终端(例如，手机)进行扫码请求充电，响应于充电请求，充电桩开始对车辆充电。在充电完成后，充电桩可以和服务器进行订单通信，由充电桩向服务器上传充电订单，汇报停止充电的原因。在一些实施例中，处理设备112可以通过网络120实时地从充电桩获取订单的信息。在一些实施例中，处理设备112可以 通过网络120周期性地(例如，每天、每周、每月)从充电桩获取订单的信息。
停止充电的原因可以包括正常停止和异常停止。充电订单的正常停止可以是由于充电结束、用户账户费用不足等原因产生的。充电订单的异常停止可以是由于充电桩故障、车辆故障、非正常操作等原因产生的。如果停止充电的原因是正常停止，则对应的订单可以被确定为是正常订单，处理设备112可以不再对其进行分析。如果停止充电的原因是异常停止，则对应的订单可以被确定为是异常订单，处理设备112可以进一步对异常订单的信息进行分析，来确定异常订单的异常原因。关于确定异常订单的异常原因的描述可以在本申请其它地方(例如，如图7中的操作720及其描述)找到。
在820中，若订单为异常订单，且异常订单的异常原因为充电桩故障，则确定与所述异常订单对应的充电桩为异常充电桩。该步骤可以由处理设备112(例如，确定模块520)执行。
在一些实施例中，如果在历史时间段内(例如，最近一天内、最近一周内、最近一个月内、最近三个月内)，与所述充电桩相关联的异常停止的充电订单的数量占与所述充电桩相关联的所有订单的数量的比例大于比例阈值，且异常停止的原因均为充电桩故障，则确定所述充电桩为异常充电桩。在一些实施例中，如果在历史时间段内(例如，最近一天内、最近一周内、最近一个月内、最近三个月内)，与所述充电桩相关联的异常停止的充电订单的数量大于数量阈值，且异常停止的原因均为充电桩故障，则确定所述充电桩为异常充电桩。在一些实施例中，如果与所述充电桩相关联的多个连续充电订单均为异常停止，且异常停止的原因均为充电桩故障，则确定所述充电桩为异常充电桩。关于确定异常充电桩的更多描述可以在本申请其它地方(例如，如图9中的操作920及其描述)找到。
步骤830，对异常充电桩进行监控操作。该步骤可以由处理设备112(例如，控制模块530)执行。
在一些实施例中，所述监控操作可以包括隔离操作和修复操作。关于对充电桩进行监控操作的更多描述可以在本申请其它地方(例如，如图9及其描述)找到。
根据本申请的一些实施例，只对实际充电产品的订单进行分析，如果充电订单异常，那么该充电桩存在异常，如果实际充电没问题，则表示此时充电桩没有问题。由于充电桩的功能就是进行充电，充电订单是否异常已经能够完全表示出充电桩的充电功能是否正常。因此，通过对充电桩在实际充电过程中所产生的充电订单进行分析，能够及时且准确地发现充电桩故障。根据本申请的一些实施例，通过对充电桩在充电时产生 的订单进行分析，针对订单分析结果作为故障判断的依据，使得对充电桩的故障发现更为准确及时。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。在一些实施例中，充电桩可以根据充电状态数据确定异常订单，并将异常订单发送至服务器，如图6及其相关描述；服务器接收异常订单后，如果确定异常订单的异常原因为充电桩故障，则可以确定与所述异常订单对应的充电桩为异常充电桩，并对异常充电桩进行监控操作，如图8及其相关描述。
图9是根据本申请的一些实施例所示的监控充电桩的示例性流程900的流程图。流程900可以由***100执行。在一些实施例中，图9所示的流程900的一个或以上操作可以在图1所示的***100中实现。例如，图9所示的流程900可以以指令的形式存储在存储设备中，并由服务器110(例如，处理设备112)调用和/或执行。以下所示流程的操作仅出于说明的目的。在一些实施例中，流程900可以包括一个或以上未描述的附加操作和/或一个或以上没有讨论的操作。另外，图9所示和下面描述的流程的操作顺序不是限制性的。
在910中，从充电桩获取订单的信息并对所述订单的信息进行分析。该步骤可以由处理设备112(例如，获取模块510)执行。
关于获取订单信息并对订单信息进行分析的描述可以在本申请其它地方(例如，如图8中的操作810及其描述)找到。
在920中，如果与所述充电桩相关的多个连续订单均为异常停止，且异常停止的原因均为充电桩故障，则确定所述充电桩为异常充电桩。该步骤可以由处理设备112(例如，确定模块520)执行。
在一些实施例中，如果连续的异常停止的充电订单数量超过预设阈值，且异常停止的原因均为充电桩异常，则将该充电桩设置为异常充电桩。例如，如果连续五笔充电订单均为异常停止，且异常停止的原因均为充电桩异常，则将该充电桩设置为异常充电桩。
在930中，对异常充电桩进行隔离操作。该步骤可以由处理设备112(例如，控制模块430)执行。
在一些实施例中，在处理设备112确定异常充电桩后，为了防止其他用户继续 选择该异常充电桩进行充电操作，处理设备112可以将异常充电桩进行隔离。所述隔离操作包括：响应于从客户端获取充电请求，如果所述充电请求所请求的充电桩为所述异常充电桩，则向所述客户端返回所述异常充电桩异常的信息，和/或向所述客户端提供异常充电桩以外的其它正常充电桩的引导信息。例如，当司机对异常充电桩进行扫码充电时，主动告知司机该充电桩异常，提示引导司机去当前充电站的其他充电桩充电。这样可以让司机第一时间感知充电桩异常，提高整体充电站的运行效率，节省司机的时间。
在940中，对异常充电桩进行修复操作。该步骤可以由处理设备112(例如，控制模块530执行)。
在一些实施例中，在处理设备112确定异常充电桩后，可以通过修复充电桩以实现对异常充电桩的维护。所述修复操作包括：确定所述异常充电桩的版本是否为最新可用版本，响应于确定所述异常充电桩的版本为最新可用版本，则向所述异常充电桩发送重启指令；响应于确定所述异常充电桩的版本不是最新可用版本，则向所述异常充电桩发送升级指令。
根据本申请的一些实施例，可以对出现故障的充电桩进行隔离操作，通过及时引导司机去别的正常充电桩充电节约时间，提高整个充电桩的运行效率。另外，还可以对异常充电桩提供自动修复功能，使充电桩的修复更为高效。
在950中，在执行修复操作后，如果在预设时间段内仍然接收到异常充电桩发送的异常订单的信息，且异常原因为充电桩故障，则向相应处理人员的终端发送关于异常充电桩的维护工单。该步骤可以由处理设备112(例如，控制模块530)执行。
预设时间段可以是存储在存储设备(例如，存储设备150)中的默认参数。附加地或替代地，预设时间段可以根据不同情况手动设置或由***100的一个或以上组件确定。例如，预设时间段可以是12小时、24小时、一周等。
在一些实施例中，***100的存储设备(例如，存储设备150)中可以预存充电桩与处理人员的映射关系和/或充电桩故障原因与处理人员的映射关系。处理设备112可以根据异常充电桩的信息(例如，充电桩的编号、充电桩的地理位置)和/或异常充电桩的故障原因(例如，枪头故障、柜门故障)，确定相应的处理人员。进一步地，处理设备可以向相应处理人员的终端发送关于异常充电桩的维护工单。维护工单可以包括异常充电桩的信息(例如，异常充电桩编号、异常充电状态数据、异常充电桩历史维修记录)、异常充电桩所在充电站的信息(例如，充电站地理位置、充电站编号、充电站充电桩的数量)等。处理人员在接收到维护工单后，可以根据异常充电桩的信息对异常充 电桩进行维修。
步骤960，在执行所述修复操作后，如果在预设时间段内未接收到所述异常充电桩发送的异常订单信息，则将所述异常充电桩设置为正常充电桩。该步骤可以由处理设备112(例如，控制模块530)执行。
在一些实施例中，在所述异常充电桩设置为正常充电桩后，处理设备112不再对该充电桩进行隔离操作，用户可以正常使用该充电桩。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。例如，操作930和操作940可以同步执行。又例如，操作930或操作940可以省略。在一些实施例中，对于在预设时间段内接收到异常充电桩发送异常停止的充电订单，但异常停止的原因不是充电桩的故障，可以采用其它的方法处理(例如，提醒用户、保存记录)。例如，如果异常订单的异常原因是车辆故障，则可以向用户终端发送关于车辆故障的提醒。又例如，如果异常订单的异常原因是非正常操作，则可以向用户终端发送安全操作规范的提醒。关于异常订单的异常原因的处理方式的更多描述可以在本申请的其它地方(例如，图7及其描述)找到。
图10是根据本申请的一些实施例所示的充电桩监控方法的示例性流程1000流程图。
在1001中，用户(例如，司机)发起充电请求。例如，司机可以通过客户终端的用户界面(例如，应用程序)向充电桩发起充电请求。又例如，司机可以通过使用客户终端扫描充电桩上的二维码发起充电请求。
在1002中，响应于用户发起的充电请求，服务器返回充电桩是否正常。如果充电桩异常，则执行步骤1003，对充电桩进行隔离操作。如果充电桩正常，则执行步骤1004。
在1003中，引导用户前往其他充电桩充电。
在1004中，充电桩对车辆进行充电操作。
在1005中，充电桩停止充电。
在1006中，判断充电桩是否正常停止充电。如果是正常停止充电，则流程结束。如果是异常停止充电，则执行操作1007。
在1007中，判断异常停止充电是否是由于充电桩问题(例如，充电桩发生故障) 导致。如果异常停止充电不是由于充电桩问题导致，则流程结束。如果异常停止充电是由于充电桩问题导致，则执行操作1008。
在1008中，判断与充电桩相关的异常停止充电订单的数量是否超过一定阈值(例如，已连续累计5笔)，且异常停止充电均是由于充电桩问题导致的。如果没有累计5笔，则流程结束。如果已累计5笔，则执行操作1009，对充电桩进行修复操作。
在1009中，判断充电桩的版本是否为最新可用版本。如果充电桩的版本已是最新版本，执行操作1010，重启充电桩。如果充电桩的版本不是最新版本，执行操作1011，升级充电桩版本。
在对充电桩进行修复操作后，执行操作1012，判断充电桩的问题是否恢复。如果恢复充电桩的问题已恢复，则流程结束。如果充电桩仍然存在问题，则执行操作1013，将工单发送给充电桩桩企业人员进一步处理。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。
图11是根据本申请的一些实施例所示的识别充电桩故障的示例性流程1100的流程图。流程1100可以由***100执行。在一些实施例中，图11所示的流程1100的一个或以上操作可以在图1所示的***100中实现。例如，图11所示的流程1100可以以指令的形式存储在存储设备中，并由服务器110(例如，处理设备112)调用和/或执行。以下所示流程的操作仅出于说明的目的。在一些实施例中，流程1100可以包括一个或以上未描述的附加操作和/或一个或以上没有讨论的操作。另外，图11所示和下面描述的流程的操作顺序不是限制性的。
在1110中，获取服务器接收当前通讯数据的时间点，所述通讯数据由充电桩发送。该步骤可以由处理设备112(例如，获取模块510)执行。
通讯数据可以包括心跳信号和充电状态数据等。心跳信号是指充电桩在工作状态下(包括充电过程和非充电过程)向服务器发送的数据(例如，累计充电量、桩功率、累计充电时长、累计充电金额)。例如，正常情况下，每一个充电桩为了“证明”其自身处于工作状态，会定期或不定期的向服务器发送通讯数据，一般称之为“心跳包”或“心跳信号”。服务器收到充电桩上报的心跳信号后，就可以认为该充电桩目前处于在线状态。充电状态数据是指充电桩在充电过程中向服务器发送的数据。充电状态数据可以包括充电桩的状态数据(例如，充电桩可操作部件的状态数据)、充电桩与车辆之间的交 互数据、充电开启或结束时发送的提醒信号、充电过程中与充电量计算相关的信号、充电结束后发送的账单数据等，如本申请其它地方所描述的(例如，图6及其相关描述)。例如，充电桩在为车辆充电的过程中，会定期或不定期的上报充电过程数据(例如，充电电量、充电时长)，充电完成后，充电桩还会向服务器上报充电账单数据。因此，理论上，只要服务器收到充电桩上报的任意阶段的充电桩上报的数据，都可以认为在该时刻充电桩是处于在线状态。
由于服务器和充电桩是属于物联网中的具有通信连接的设备，因此充电桩可以向服务器(例如，处理设备112)发送通讯数据，服务器在接收到通讯数据后，可以直接确定本次接收到通讯数据的时刻。
在1120中，以所述时间点为起点，确定在预设第一时间阈值内服务器是否收到新的通讯数据。该步骤可以由处理设备112(例如，确定模块520)执行。
第一时间阈值可以是存储在存储设备(例如，存储设备150)中的默认值。附加地或替代地，第一时间阈值可以根据不同情况手动设置或由***100的一个或以上组件确定。在一些实施例中，第一时间阈值可以根据充电桩所处位置的网络稳定性来确定。网络稳定性可以与充电桩的品牌、网络运营商等有关。例如，对于网络信号强覆盖的地区，第一阈值可以设置的相对较短(例如，5-8分钟之间)。对于网络信号覆盖弱的地区，第一阈值可以设置的相对较长(例如，15分钟左右)。
在一些实施例中，新的通讯数据与当前通讯数据的类型可以是相同的也可以是不同的，只要是从充电桩获取的通讯数据即可。
在1130中，响应于确定在预设第一时间阈值内服务器没有接收到新的通讯数据，确定充电桩存在离线故障点。该步骤可以由处理设备112(例如，确定模块520)执行。
充电桩存在离线故障点可以指充电桩在某一时间点处于离线状态。充电桩存在离线故障点的原因可能是充电桩故障，也可能是由于网络不稳定(例如，网络抖动导致的暂时性离网)。在一些实施例中，离线故障点可以与当前通讯数据的接收时间点与当前接收时刻加上第一时间阈值后的时间点之间的任一时间点相关联。例如，离线故障点可以与当前通讯数据的接收时间点关联，也可以与当前接收时刻加上第一时间阈值后的时间点进行关联。即，可以认为离线故障点是在接收当前通讯数据的时间点产生的，也可以认为离线故障点是在接收当前通讯数据的时间点加上第一时间阈值的时间点产生的，或者上述两个时间点之间产生。仅作为示例，假设处理设备112在2020年6月1 日8：00从1号充电桩接收到通讯数据，第一时间阈值为10分钟，且处理设备112在2020年6月1日8：10仍未接收到新的通讯数据，则处理设备112可以认为1号充电桩存在离线故障点，离线故障点的产生时间可以认为是8：00至8：10之间的任一时间点。
在确定充电桩存在离线故障点之后，处理设备112可以进一步确定充电桩是否存在故障。在一些实施例中，处理设备112可以确定所述充电桩是否存在连续的离线故障点且所述连续的离线故障点的个数是否超过故障点阈值。充电桩存在连续离线故障点可以反映充电桩在多个连续的时间点处于离线状态，即可以确定充电桩离线的原因是充电桩存在故障而非网络不稳定。响应于确定所述充电桩存在连续的离线故障点且所述连续的离线故障点个数超过故障点阈值，则确定所述充电桩存在故障。例如，如果充电桩存在连续5个离线故障点，则确定充电桩存在故障。
在一些实施例中，以所述时间点为起点，处理设备112可以确定在预设第二时间阈值内所述服务器是否未接收到新的通讯数据。第二时间阈值大于第一时间阈值。例如，第二时间阈值可以选择为第一时间阈值的倍数。仅作为示例，当第一时间阈值设置为15分钟时，第二时间阈值可以设置在1.5小时-2小时的范围内。响应于确定在预设第二时间阈值内所述服务器没有接收到新的通讯数据，则处理设备112可以确定所述充电桩存在故障。
根据本申请的一些实施例，服务器能够始终记录待识别充电桩上报的通讯数据的时间轨迹，如果超过第一时间阈值的时长后依然没有收到任何通讯数据则可以确定该充电桩存在一个离线故障点，离线故障点可以与本次通讯数据的接收时刻关联也可以与本次接收时刻加上第一时间阈值后的时刻点进行关联。如果连续出现多个故障点(例如四个以上)，就可以确定待识别充电桩存在离线故障了。这种方式能够排除因为偶尔的信号抖动而误判为离线故障的情况，提高了离线故障识别的准确性。而第二预设时间已经是较长的时间段了，如果超过第二预设时间依然无法接收到新的通讯数据则可以直接判定该充电桩存在离线故障。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。
在一些实施例中，流程1100还可以包括其它步骤。例如，响应于确定充电桩存在离线故障点，处理设备112可以获取所述充电桩的设备属性以及与所述充电桩的设备属性对应的第一终端属性。处理设备112可以根据所述第一终端属性发送故障提醒信息 至第一终端，所述故障提醒信息包括所述充电桩的设备属性。又例如，处理设备112可以获取充电站中被确定为存在离线故障点的充电桩占充电桩总数的比例，处理设备112可以确定所述比例是否超过阈值，响应于确定所述比例超过所述阈值，处理设备112可以获取所述充电站的站点属性以及与所述站点属性对应的第二终端属性，处理设备112可以根据所述第二终端属性发送报警信息至第二终端，所述报警信息包括所述充电站的站点属性。关于发送故障提醒信息和报警信息的更多描述可以在本申请的其它地方(例如，图13及其相关描述)找到。
在一些实施例中，操作1120和操作1130可以省略，例如，如果当前通讯数据中包括故障信息，则处理设备112可以直接确定充电桩存在故障。如本申请其它地方所描述的，充电桩内部的传感器可以检测充电桩的实际状态数据，如果发现某个部件的状态数据异常，则充电桩可以生成故障信息，并将故障信息作为通讯数据的一部分上报给服务器，服务器在接收到故障信息之后，就可以确定充电桩存在离线故障。但是如果网络发生故障，导致服务器一直无法成功接收故障信息，这时则可以通过流程1100对充电桩进行故障检测。因此，根据本申请的一些实施例，能够结合充电桩主动上报和服务器被动检测两种方式对充电桩的故障进行识别，更及时的发现充电桩的故障。
图12是根据本申请的一些实施例所示的识别充电桩故障的示例性流程1200的流程图。流程1200可以由***100执行。在一些实施例中，图12所示的流程1200的一个或以上操作可以在图1所示的***100中实现。例如，图12所示的流程1200可以以指令的形式存储在存储设备中，并由服务器110(例如，处理设备112)调用和/或执行。以下所示流程的操作仅出于说明的目的。在一些实施例中，流程1200可以包括一个或以上未描述的附加操作和/或一个或以上没有讨论的操作。另外，图12所示和下面描述的流程的操作顺序不是限制性的。
在1210中，获取服务器接收当前通讯数据的时间点，所述通讯数据由充电桩发送。该步骤可以由处理设备112(例如，获取模块510)执行。
关于获取服务器接收当前通讯数据的时间点的细描述可以在本申请的其它地方(例如，图11中的操作1110)找到。
在1220中，以所述时间点为起点，确定在预设第一时间阈值内服务器是否接收到新的通讯数据。该步骤可以由处理设备112(例如，确定模块520)执行。
关于确定在预设第一时间阈值内所述服务器是否接收到新的通讯数据的细描述可以在本申请的其它地方(例如，图11中的操作1120)找到。
在1230中，响应于确定在预设第一时间阈值内服务器没有接收到新的通讯数据，且充电状态数据中包括订单异常信息，则对异常订单生成订单异常标识符。该步骤可以由处理设备112(例如，确定模块520)执行。
在一些实施例中，处理设备112可以判断当前通讯数据中的充电状态数据中是否包括异常状态数据。响应于确定充电状态数据中包括异常状态数据，则处理设备112可以确定所述订单为异常订单，并对异常订单生成订单异常标识符(例如，第一标识符、第二标识符)。在一些实施例中，如图6的相关描述，充电桩可以确定充电状态数据中是否包括异常状态数据，如果确定所述充电状态数据中包括异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符，并进一步地将标识符发送给处理设备112。即，在不同的应用场景中，对异常订单生成标识符的操作的执行主体可以是充电桩，也可以是处理设备112，本申请不做任何限制。关于对异常订单生成标识符的描述可以在本申请的其它地方(例如，图6及其相关描述)找到。
在1240中，获取所述充电桩的历史异常订单数量和历史订单总数量。该步骤可以由处理设备112(例如，获取模块510)执行。
在一些实施例中，处理设备112可以统计第一历史时间段内与所述充电桩相关历史异常订单数量和第二历史时间段内与所述充电桩相关的历史订单总数量。在一些实施例中，第一历史时间段与第二历史时间段可以不同。在一些实施例中，第一历史时间段与第二历史时间段可以相同，进而能够降低数据分析量，提高效率。在一些实施例中，历史时间段(例如，第一历史时间段、第二历史时间段)可以是存储在存储设备(例如，存储设备150)中的默认值。附加地或替代地，历史时间段(例如，第一历史时间段、第二历史时间段)可以根据不同情况手动设置或由***100的一个或以上组件确定。例如，历史时间段可以是最近三天内、最近一周内、最近一个月内、最近三个月内等。
在1250中，确定充电桩的历史异常订单数量占历史订单总数量的比例是否超过比例阈值。该步骤可以由处理设备112(例如，确定模块520)执行。
在1260中，响应于确定所述充电桩的历史异常订单数量占历史订单总数量的比例超过所述比例阈值，则确定所述充电桩存在故障。该步骤可以由处理设备112(例如，确定模块520)执行。响应于确定所述充电桩的历史异常订单数量占历史订单总数量的比例不超过所述比例阈值，则确定所述充电桩不存在故障。
在一些实施例中，比例阈值可以是存储在存储设备(例如，存储设备150)中的默认值。附加地或替代地，比例阈值可以根据不同情况手动设置或由***100的一个或 以上组件确定。在一些实施例中，比例阈值可以设置在30％-50％之间。仅作为示例，假设比例阈值设置为50％，如果一台充电桩在过去三天内出现了超过50％的账单异常信息，则可以认为该充电桩存在故障。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。
图13是根据本申请的一些实施例所示的识别充电桩故障的示例性流程1300的流程图。流程1300可以由***100执行。在一些实施例中，图13所示的流程1300的一个或以上操作可以在图1所示的***100中实现。例如，图13所示的流程1300可以以指令的形式存储在存储设备中，并由服务器110(例如，处理设备112)调用和/或执行。以下所示流程的操作仅出于说明的目的。在一些实施例中，流程1300可以包括一个或以上未描述的附加操作和/或一个或以上没有讨论的操作。另外，图13所示和下面描述的流程的操作顺序不是限制性的。
在1310中，获取服务器接收当前通讯数据的时间点，所述通讯数据由充电桩发送，所述通讯数据包括充电状态数据。该步骤可以由处理设备(例如，获取模块510)执行。
关于获取服务器接收当前通讯数据的时间点的描述可以在本申请的其它地方(例如，图11中的操作1110)找到。
在1320中，以所述时间点为起点，确定在预设第一时间阈值内服务器是否接收到新的通讯数据。该步骤可以由处理设备112(例如，确定模块520)执行。
关于确定在预设第一时间阈值内所述服务器是否接收到新的通讯数据的描述可以在本申请的其它地方(例如，图11中的操作1120)找到。
在1330中，响应于确定在预设第一时间阈值内所述服务器接收到新的通讯数据，获取充电桩的状态数据。该步骤可以由处理设备112(例如，获取模块510)执行。
例如，如果通讯数据中包括充电桩的状态数据，则处理设备112可以直接从通讯数据中提取充电桩的状态数据。又例如，如果通讯数据中不包括充电桩的状态数据，则处理设备112可以从充电桩(例如，传感器)获取相应部件的状态数据。
在1340中，确定所述充电桩的状态数据是否在预设范围内。该步骤可以由处理设备112(例如，确定模块520)执行。
充电桩的状态数据的预设范围是指所述充电桩在正常工作状态下的状态数据的 标准范围。在一些实施例中，充电桩的可操作部件的每一种状态数据都有其相应的预设标准范围。例如，充电枪端头的状态数据可以包括充电枪端头的电流的预设标准范围、充电枪端头的温度的预设标准范围、充电枪端头的电压的预设标准范围等。
在一些实施例中，所述预设标准范围可以预先存储在***100的存储设备(例如，存储设备150)中，处理设备112可以从存储设备中获取预设标准范围。在一些实施例中，所述预设标准范围可以是***100的组件(例如，处理设备112)设置的，也可以是***100的用户根据充电桩的型号设置的。
在1350中，响应于确定所述充电桩的状态数据不在所述预设范围内，则确定所述充电桩存在故障。该步骤可以由处理设备112(例如，确定模块520)执行。
在一些实施例中，响应于确定充电桩的任意一种类型的状态数据不在其相应的预设范围内，则处理器112可以确定所述充电桩存在故障。在一些实施例中，响应于确定充电桩的某种预设类型的状态数据不在其相应的预设范围内，则处理器112可以确定所述充电桩存在故障。例如，只有当确定充电桩的充电枪或桩体的状态数据不在相应的预设范围内时，才确定充电桩存在故障。
在1360中，根据第一终端属性发送故障提醒信息至第一终端，故障提醒信息包括充电桩的设备属性。该步骤可以由处理设备112(例如，控制模块530)执行。
在一些实施例中，响应于确定充电桩存在故障，处理设备112可以获取所述充电桩的设备属性以及与所述充电桩的设备属性对应的第一终端属性。例如，处理设备112可以根据充电桩故障类型和/或充电桩的设备属性与第一终端属性之间的对应关系，确定与所述充电桩设备属性对应的第一终端属性。处理设备112可以根据所述第一终端属性发送故障提醒信息至第一终端。
充电桩的设备属性可以包括充电桩的信息，例如，充电桩型号、充电桩品牌、充电桩编号、充电桩地理位置等。第一终端可以是处理人员(例如，维修人员)所佩戴的通讯设备(例如，手机)。第一终端属性可以包括第一终端的信息，例如，与第一终端相关联的用户的信息(例如，处理人员的身份信息)、第一终端的型号等。在一些实施例中，处理设备112可以根据预设的通讯方式，例如，短信、微信、自动拨号进行语音呼叫等，发送故障提醒信息，以便于维修人员及时对故障的充电桩进行维修。故障信息可以包括充电桩的故障、充电桩的信息(例如，充电桩的编号、充电桩的地理位置)等。故障信息可以是文字信息、语音信息、视频信息、图片信息等。
在1370中，获取充电站中被确定为存在故障的充电桩占充电桩总数的比例。该 步骤可以由处理设备112(例如，获取模块510)执行。
在一些实施例中，处理设备112可以根据存在故障的充电桩的信息(例如，充电桩编号、充电桩地理位置)确定存在故障的充电桩所在的充电站。例如，***100的存储设备(例如，存储设备150)中可以存储充电桩编号与充电站编号的对应关系，处理设备112可以从存储设备获取充电桩编号与充电站编号的对应关系，并根据存在故障的充电桩的编号，确定存在故障的充电桩所在的充电站的编号。而后，处理设备112可以统计充电站中所有被确定为存在故障的充电桩的数量和充电站中的所有充电桩的总数。进一步地，处理设备112可以确定充电站中所有被确定为存在故障的充电桩占充电站中的充电桩总数的比例。
在1380中，确定所述比例是否超过阈值。该步骤可以由处理设备112(例如，确定模块520)执行。
在一些实施例中，阈值可以是存储在存储设备(例如，存储设备150)中的默认值。附加地或替代地，阈值可以根据不同情况手动设置或由***100的一个或以上组件确定。仅作为示例，阈值可以设置为30％，也就是说当一个充电站内有30％的充电桩出现了故障就可以上报该充电站的负责人。
在1390中，响应于确定所述比例超过所述阈值，获取所述充电站的站点属性以及与所述站点属性对应的第二终端属性。该步骤可以由处理设备112(例如，确定模块520)执行。
当充电站中被确定为存在故障的充电桩占充电桩总数的比例超过阈值时，说明很大可能是因为网络问题或服务问题等导致集体性故障，这时需要运营商平台介入解决问题。在一些实施例中，处理设备112可以根据充电站的站点属性与第二终端属性之间的对应关系，确定与所述充电站的站点属性对应的第二终端属性。充电站的站点属性可以包括充电站的信息，例如，充电站的地理位置、充电站的编号、充电站中充电桩的历史订单、充电站中充电桩的历史维修记录等或其任意组合。第二终端可以是处理人员(例如，充电站负责人)所佩戴的通讯设备(例如，手机)。第二终端属性可以包括第二终端的信息，例如，与第二终端相关联的用户的信息(例如，充电站负责人的身份信息)、第二终端的型号等。
在1391中，根据所述第二终端属性发送报警信息至第二终端，所述报警信息包括所述充电站的站点属性。该步骤可以由处理设备112(例如，控制模块530)执行。
在一些实施例中，处理设备112可以根据预设的通讯方式，例如，短信、微信、 自动拨号进行语音呼叫等，发送报警信息，以便于充电站负责人及时处理充电站的故障。报警信息可以包括充电站的信息(例如，充电站的编号)、充电站中充电桩的故障、充电站中发生故障的充电桩的数量等。报警信息可以是文字信息、语音信息、视频信息、图片信息等。
根据本申请的一些实施例，当某一个充电站中有较多充电桩出现故障时，能够及时地通知到充电站的负责人，例如，通过发送短信、发送微信、自动拨号进行语音呼叫等方式，以便尽快对故障处理，缩短充电桩不可用的时长。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。例如，可以同步执行操作1370和操作1380。又例如，可以省略操作1370至1391或省略操作1360。
图14是根据本申请的一些实施例所示的示例性充电监控***的示意图。
如图14所示，充电监控***可以包括客户终端1410、充电桩1420、平台服务器1430、电动车辆1440和处理人终端1450。充电桩1420可以包括多个传感器1421和控制器1422。电动车辆1440的司机可以使用客户终端1410扫描充电码向充电桩1420发起充电请求。充电桩1420可以基于充电请求生成充电订单，或者将充电请求发送至平台服务器1430，平台服务器1430可以协调充电站中充电桩的资源(例如，为司机推荐其它空闲充电桩)，并基于充电请求生成充电订单。在充电过程中，充电桩1420中的多个传感器1421可以检测充电桩1420的实际状态数据。例如传感器1421可以包括温度传感器1、电流传感器2、压力传感器3等。传感器1421可以将检测到的实际状态数据发送至控制器1422。控制器1422可以通过确定实际状态数据是否在相应的预设标准范围内，确定充电桩1420是否存在故障。如果确定充电桩1420存在故障，控制器1422可以产生故障信息，并将故障信息发送至平台服务器1430。响应于故障信息，平台服务器1430可以产生故障提醒信息并将故障提醒信息发送至相应的处理人终端1450。
应该注意的是，上述描述仅出于说明性目的而提供，并不旨在限制本申请的范围。对于本领域的普通技术人员来说，可以根据本申请的描述，做出各种各样的变化和修改。然而，这些变化和修改不会背离本申请的范围。
图15A是根据本申请的一些实施例所示的充电桩与平台服务器之间的数据传输过程的示例性示意图。如图15A所示，充电桩可以定期或不定期的向平台服务器发送心跳信号(也可以成为“心跳包”)(例如，累计充电量、桩功率、累计充电时长、累计 充电金额)。平台服务器收到充电桩上报的心跳信号后，就可以认为该充电桩目前处于在线状态。
图15B是根据本申请的一些实施例所示的充电桩与平台服务器之间的账单传输过程的示例性示意图。如图15B所示，当充电结束后，充电桩可以向平台服务器上报充电账单。相应地，平台服务器在收到充电账单后，会向充电桩发送响应信息。
如果充电过程正常完成则正常生成充电账单，如果充电账单生成时因为某些故障原因中断(例如，充电枪连接松动)导致无法正常生成充电账单时，则发送账单异常信号。无论哪种情况，充电桩都会一直尝试向平台服务器发送账单相关信息，直到接收到平台服务器的响应信号，如果平台服务器一直无法接收成功，则平台服务器可以根据流程1100判断充电桩是否存在离线故障。
图15C是根据本申请的一些实施例所示的充电桩与平台服务器之间的故障信号传输过程的示例性示意图。
充电桩内部设置的传感器可以检测充电桩的实际状态数据。传感器可以将检测到的实际状态数据发送至充电桩的控制器，控制器可以通过确定实际状态数据是否在相应的预设标准范围内，确定充电桩是否存在故障。如果确定充电桩存在故障，控制器可以产生故障信息，并将故障信息发送至平台服务器。相应地，平台服务器在收到故障信息后，会向充电桩发送响应信息。
本申请的实施例可能带来的有益效果包括但不限于：(1)在确定异常充电桩后，通过对出现故障的充电桩进行隔离及修复操作，可以使充电桩的修复更为高效，提高整个充电桩的运行效率；(2)服务器可以根据接收到充电桩数据后的时间阈值内是否接收到新的通讯数据的结果，确定充电桩是否发生离线故障，可以排除因为偶尔的信号抖动而误判为离线故障的情况，提高离线故障识别的准确性；(3)通过结合充电桩主动上报和服务器被动检测两种方式对充电桩的故障进行识别，可以更及时的发现充电桩的故障。需要说明的是，不同实施例可能产生的有益效果不同，在不同的实施例里，可能产生的有益效果可以是以上任意一种或几种的组合，也可以是其他任何可能获得的有益效果。
上文已对基本概念做了描述，显然，对于本领域的普通技术人员来说，上述申请披露仅作为示例，并不构成对本申请的限制。虽然此处并未明确说明，但本领域的普通技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进和修正仍属于本申请示例性实施例的精神和范围。
同时，本申请使用了特定术语来描述本申请的实施例。例如“一个实施例”、“一实施例”和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应当强调并注意的是，本说明书中在不同位置两次或以上提及的“一实施例”、“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本申请的一个或以上实施例中的某些特征、结构或特点可以进行适当的组合。
此外，本领域的普通技术人员可以理解，本申请的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的过程、机器、产品或物质的组合，或对其任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固体、常驻软件、微代码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“单元”、“模块”或“***”。此外，本申请的各方面可以采取体现在一个或以上计算机可读介质中的计算机程序产品的形式，其中计算机可读程序代码包含在其中。
计算机可读信号介质可能包含一个内含有计算机程序代码的传播数据信号，例如在基带上或作为载波的一部分。此类传播信号可以有多种形式，包括电磁形式、光形式等或任何合适的组合。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行***、装置或设备以实现通信、传播或传输供使用的程序。位于计算机可读信号介质上的程序代码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、RF等，或任何上述介质的组合。
本申请各部分操作所需的计算机程序代码可以用任意一种或以上程序语言编写，包括面向主体编程语言如Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C++、C#、VB.NET、Python等，常规程序化编程语言如C语言、VisualBasic、Fortran2003、Perl、COBOL 2002、PHP、ABAP，动态编程语言如Python、Ruby和Groovy，或其他编程语言等。该程序代码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后一种情况下，远程计算机可以通过任何类型的网络(包括局域网(LAN)或广域网(WAN))连接到用户的计算机，或者可以连接到外部计算机(例如，通过互联网)，或在云计算环境中，或作为服务提供(例如，软件即服务(SaaS))。
此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明申请实施例，但应当理解的是，该类细 节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的***组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的***。
同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或以上发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。然而，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

Claims (49)

  1. 一种充电桩故障识别的方法，其特征在于，包括：
    响应于获取充电请求，对所述充电请求生成订单；
    在对车辆执行当前充电操作过程中，获取充电状态数据；
    确定所述充电状态数据中是否包括异常状态数据；
    响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符；以及
    发送所述异常订单至与所述充电桩连接的服务器。
  2. 根据权利要求1所述的方法，其特征在于，所述充电状态数据包括充电桩可操作部件的状态数据，响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符，包括：
    响应于确定所述充电桩可操作部件的状态数据为异常状态，则对所述异常订单生成第一标识符。
  3. 根据权利要求1所述的方法，其特征在于，所述充电状态数据包括充电桩与所述车辆之间的交互数据，响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符，包括：
    响应于确定所述交互数据为异常状态，则对所述异常订单生成第二标识符。
  4. 根据权利要求1所述的方法，其特征在于，对所述异常订单生成与所述异常状态数据对应的标识符，包括：
    获取异常状态数据与标识符之间的映射关系；以及
    根据所述映射关系和异常状态数据，确定所述异常订单的标识符。
  5. 一种充电桩故障识别和监控的方法，其特征在于，包括：
    获取异常订单的信息，所述异常订单反映充电桩进行充电操作时存在异常状态数据的情况，所述异常订单的信息中包括与所述异常状态数据对应的标识符；以及
    根据所述标识符，确定所述异常订单的异常原因。
  6. 根据权利要求5所述的方法，其特征在于，所述异常原因包括充电桩故障、车辆故障和非正常操作中的至少一项。
  7. 根据权利要求5所述的方法，其特征在于，根据所述标识符，确定所述异常订单的异常原因，包括：
    获取与所述异常订单对应的充电桩信息；
    获取历史时间段内与所述充电桩信息对应的历史异常订单的信息；
    获取所述历史异常订单的信息中的历史标识符；以及
    根据所述标识符在所述历史标识符中的所占比例确定所述异常订单的异常原因。
  8. 根据权利要求7所述的方法，其特征在于，所述标识符为第一标识符，所述第一标识符指示所述充电桩的可操作部件的状态数据为异常状态，根据所述标识符，确定所述异常订单的异常原因，包括：
    确定所述第一标识符在所述历史标识符中的所占比例是否大于阈值。
  9. 根据权利要求8所述的方法，其特征在于，所述方法进一步包括：
    响应于确定所述第一标识符在所述历史标识符中的所占比例大于所述阈值，则确定所述异常原因为充电桩故障。
  10. 根据权利要求8所述的方法，其特征在于，所述方法进一步包括：
    响应于确定所述第一标识符在所述历史标识符中的所占比例小于所述阈值，则确定所述异常原因为非正常操作。
  11. 根据权利要求7所述的方法，其特征在于，所述标识符为第二标识符，所述第二标识符指示所述充电桩与被充电的车辆之间的交互数据为异常状态，根据所述标识符，确定所述异常订单的异常原因，包括：
    确定所述第二标识符在所述历史标识符中的所占比例是否大于阈值。
  12. 根据权利要求11所述的方法，其特征在于，所述方法进一步包括：
    响应于确定所述第二标识符在所述历史标识符中的所占比例大于所述阈值，则确定所述异常原因为充电桩故障。
  13. 根据权利要求11所述的方法，其特征在于，所述方法进一步包括：
    响应于确定所述第二标识符在所述历史标识符中的所占比例小于所述阈值，则确定所述异常原因为车辆故障。
  14. 根据权利要求5所述的方法，其特征在于，所述方法进一步包括：
    生成异常状态数据与标识符之间的映射关系；以及
    发送所述映射关系至所述充电桩。
  15. 根据权利要求5所述的方法，其特征在于，所述方法进一步包括：
    生成异常原因与处理人员之间的映射关系；以及
    发送所述异常原因至相应处理人员的终端。
  16. 根据权利要求5所述的方法，其特征在于，所述异常订单的异常原因是充电桩故障，所述方法进一步包括：
    确定与所述异常订单对应的充电桩为异常充电桩；以及
    对所述异常充电桩进行监控操作。
  17. 根据权利要求16所述的方法，其特征在于，确定与所述异常订单对应的充电桩为异常充电桩，包括：
    如果与所述充电桩相关的多个连续充电订单均为异常停止，且异常停止的原因均为充电桩故障，则确定所述充电桩为异常充电桩。
  18. 根据权利要求16所述的方法，其特征在于，所述监控操作包括隔离操作，所述隔离操作包括：
    响应于从客户端获取充电请求，如果所述充电请求所请求的充电桩为所述异常充电桩，则向所述客户端返回所述异常充电桩异常的信息，和/或向所述客户端提供异常充 电桩以外的其它正常充电桩的引导信息。
  19. 根据权利要求16所述的方法，其特征在于，所述监控操作包括修复操作，所述修复操作包括：
    确定所述异常充电桩的版本是否为最新可用版本。
  20. 根据权利要求19所述的方法，其特征在于，所述修复操作进一步包括：
    响应于确定所述异常充电桩的版本为最新可用版本，则向所述异常充电桩发送重启指令。
  21. 根据权利要求19所述的方法，其特征在于，所述修复操作进一步包括：
    响应于确定所述异常充电桩的版本不是最新可用版本，则向所述异常充电桩发送升级指令。
  22. 根据权利要求19所述的方法，其特征在于，在执行所述修复操作后，如果在预设时间段内仍然接收到所述异常充电桩发送的异常订单的信息，且异常原因为充电桩故障，则向相应处理人员的终端发送关于所述异常充电桩的维护工单。
  23. 根据权利要求19所述的方法，其特征在于，在执行所述修复操作后，如果在预设时间段内未接收到所述异常充电桩发送的异常订单信息，则将所述异常充电桩设置为正常充电桩。
  24. 一种充电桩故障识别的方法，其特征在于，包括：
    获取服务器接收当前通讯数据的时间点，所述通讯数据由充电桩发送；
    以所述时间点为起点，确定在预设第一时间阈值内所述服务器是否接收到新的通讯数据；以及
    响应于确定在预设第一时间阈值内所述服务器没有接收到新的通讯数据，则确定所述充电桩存在离线故障点。
  25. 根据权利要求24所述的方法，其特征在于，进一步包括：
    确定所述充电桩是否存在连续的离线故障点且所述连续的离线故障点的个数超过故障点阈值；以及
    响应于确定所述充电桩存在连续的离线故障点且所述连续的离线故障点个数超过故障点阈值，则确定所述充电桩存在故障。
  26. 根据权利要求24所述的方法，其特征在于，进一步包括：
    以所述时间点为起点，确定在预设第二时间阈值内所述服务器是否未接收到新的通讯数据，其中所述第二时间阈值大于所述第一时间阈值；以及
    响应于确定在预设第二时间阈值内所述服务器没有接收到新的通讯数据，则确定所述充电桩存在故障。
  27. 根据权利要求24所述的方法，其特征在于，所述通讯数据包括心跳信号或充电状态数据。
  28. 根据权利要求27所述的方法，其特征在于，所述充电状态数据包括订单异常信号，所述方法进一步包括：
    获取所述充电桩的历史异常订单数量和历史订单总数量；
    确定所述充电桩的历史异常订单数量占历史订单总数量的比例是否超过比例阈值；以及
    响应于确定所述充电桩的历史异常订单数量占历史订单总数量的比例超过所述比例阈值，则确定所述充电桩存在故障。
  29. 根据权利要求27所述的方法，其特征在于，所述充电状态数据包括充电桩的状态数据，所述方法进一步包括：
    响应于确定在预设第一时间阈值内所述服务器接收到新的通讯数据，获取所述充电桩的状态数据；
    确定所述充电桩的状态数据是否在预设范围内；以及
    响应于确定所述充电桩的状态数据不在所述预设范围内，则确定所述充电桩存在故 障。
  30. 根据权利要求29所述的方法，其特征在于，所述充电桩的状态数据包括充电桩的可操作部件的温度、电流值、电压值、充电桩的实时输出功率、充电桩的累计充电时长和充电桩的累计充电量中的至少一项。
  31. 根据权利要求24所述的方法，其特征在于，所述通讯数据包括故障信息，所述方法进一步包括：
    确定所述充电桩存在故障。
  32. 根据权利要求25所述的方法，其特征在于，所述方法进一步包括：
    响应于确定所述充电桩存在故障，获取所述充电桩的设备属性以及与所述设备属性对应的第一终端属性；以及
    根据所述第一终端属性发送故障提醒信息至第一终端，所述故障提醒信息包括所述充电桩的设备属性。
  33. 根据权利要求32所述的方法，其特征在于，所述方法进一步包括：
    获取充电站中被确定为存在故障的充电桩占充电桩总数的比例；
    确定所述比例是否超过阈值；
    响应于确定所述比例超过所述阈值，获取所述充电站的站点属性以及与所述站点属性对应的第二终端属性；以及
    根据所述第二终端属性发送报警信息至第二终端，所述报警信息包括所述充电站的站点属性。
  34. 一种充电桩故障识别和监控的方法，其特征在于，包括：
    获取充电订单的信息，并对充电订单的信息进行分析；
    如果所述充电订单是异常停止，且异常停止的原因是充电桩异常导致的，则确定所述充电桩为异常充电桩；以及
    对所述充电桩进行监控操作。
  35. 根据权利要求34所述的方法，其特征在于，确定与所述充电桩为异常充电桩，包括：
    如果与所述充电桩相关的多个连续充电订单均为异常停止，且异常停止的原因均为充电桩故障，则确定所述充电桩为异常充电桩。
  36. 根据权利要求34所述的方法，其特征在于，所述监控操作包括隔离操作，所述隔离操作包括：
    响应于从客户端获取充电请求，如果所述充电请求所请求的充电桩为所述异常充电桩，则向所述客户端返回所述异常充电桩异常的信息，和/或向所述客户端提供异常充电桩以外的其它正常充电桩的引导信息。
  37. 根据权利要求34所述的方法，其特征在于，所述监控操作包括修复操作，所述修复操作包括：
    确定所述异常充电桩的版本是否为最新可用版本。
  38. 根据权利要求37所述的方法，其特征在于，所述修复操作进一步包括：
    响应于确定所述异常充电桩的版本为最新可用版本，则向所述异常充电桩发送重启指令。
  39. 根据权利要求37所述的方法，其特征在于，所述修复操作进一步包括：
    响应于确定所述异常充电桩的版本不是最新可用版本，则向所述异常充电桩发送升级指令。
  40. 根据权利要求37所述的方法，其特征在于，在执行所述修复操作后，如果在预设时间段内仍然接收到所述异常充电桩发送的异常订单的信息，且异常原因为充电桩故障，则向相应处理人员的终端发送关于所述异常充电桩的维护工单。
  41. 根据权利要求37所述的方法，其特征在于，在执行所述修复操作后，如果在预设时间段内未接收到所述异常充电桩发送的异常订单信息，则将所述异常充电桩设置为正常充电桩。
  42. 一种充电桩故障识别的***，包括：
    一个或以上存储设备，存储用于充电桩故障识别的一组指令；以及
    与所述一个或以上存储设备通信的一个或以上处理器，其中，当执行所述一组指令时，所述一个或以上处理器用于：
    响应于获取充电请求，对所述充电请求生成订单；
    在对车辆执行当前充电操作过程中，获取充电状态数据；
    确定所述充电状态数据中是否包括异常状态数据；
    响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符；以及
    发送所述异常订单至与所述充电桩连接的服务器。
  43. 一种充电桩故障识别和监控的***，包括：
    一个或以上存储设备，存储用于充电桩故障识别和监控的一组指令；以及
    与所述一个或以上存储设备通信的一个或以上处理器，其中，当执行所述一组指令时，所述一个或以上处理器用于：
    获取异常订单的信息，所述异常订单反映充电桩进行充电操作时存在异常状态数据的情况，所述异常订单的信息中包括与所述异常状态数据对应的标识符；以及
    根据所述标识符，确定所述异常订单的异常原因。
  44. 一种充电桩故障识别的***，包括：
    一个或以上存储设备，存储用于充电桩故障识别和监控的一组指令；以及
    与所述一个或以上存储设备通信的一个或以上处理器，其中，当执行所述一组指令时，所述一个或以上处理器用于：
    获取服务器接收当前通讯数据的时间点，所述通讯数据由充电桩发送；
    以所述时间点为起点，确定在预设第一时间阈值内所述服务器是否接收到新的通讯数据；以及
    响应于确定在预设第一时间阈值内所述服务器没有接收到新的通讯数据，则确定所述充电桩存在离线故障点。
  45. 一种充电桩故障识别和监控的***，包括：
    一个或以上存储设备，存储用于充电桩故障识别和监控的一组指令；以及
    与所述一个或以上存储设备通信的一个或以上处理器，其中，当执行所述一组指令时，所述一个或以上处理器用于：
    获取充电订单的信息，并对充电订单的信息进行分析；
    如果所述充电订单是异常停止，且异常停止的原因是充电桩异常导致的，则确定所述充电桩为异常充电桩；以及
    对所述充电桩进行监控操作。
  46. 一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现充电桩故障识别的方法，所述方法包括：
    响应于获取充电请求，对所述充电请求生成订单；
    在对车辆执行当前充电操作过程中，获取充电状态数据；
    确定所述充电状态数据中是否包括异常状态数据；
    响应于确定所述充电状态数据中包括所述异常状态数据，则确定所述订单为异常订单，并对所述异常订单生成与所述异常状态数据对应的标识符；以及
    发送所述异常订单至与所述充电桩连接的服务器。
  47. 一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现充电桩故障识别和监控的方法，所述方法包括：
    获取异常订单的信息，所述异常订单反映充电桩进行充电操作时存在异常状态数据的情况，所述异常订单的信息中包括与所述异常状态数据对应的标识符；以及
    根据所述标识符，确定所述异常订单的异常原因。
  48. 一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现充电桩故障识别的方法，所述方法包括：
    获取服务器接收当前通讯数据的时间点，所述通讯数据由充电桩发送；
    以所述时间点为起点，确定在预设第一时间阈值内所述服务器是否接收到新的通讯数据；以及
    响应于确定在预设第一时间阈值内所述服务器没有接收到新的通讯数据，则确定所 述充电桩存在离线故障点。
  49. 一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被处理器执行时，实现充电桩故障识别和监控的方法，所述方法包括：
    获取充电订单的信息，并对充电订单的信息进行分析；
    如果所述充电订单是异常停止，且异常停止的原因是充电桩异常导致的，则确定所述充电桩为异常充电桩；以及
    对所述充电桩进行监控操作。
PCT/CN2020/120248 2019-10-10 2020-10-10 充电桩故障识别的***和方法 WO2021068947A1 (zh)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
CN201910958433.0 2019-10-10
CN201910958433.0A CN110646699A (zh) 2019-10-10 2019-10-10 充电桩故障识别方法、存储介质、充电桩及电子设备
CN201911408140.1A CN111038320B (zh) 2019-12-31 2019-12-31 充电桩监控方法、电子设备及存储介质
CN201911408140.1 2019-12-31
CN202010167714.7 2020-03-11
CN202010167714.7A CN111815389A (zh) 2020-03-11 2020-03-11 充电订单异常原因确定方法、存储介质和电子设备

Publications (1)

Publication Number Publication Date
WO2021068947A1 true WO2021068947A1 (zh) 2021-04-15

Family

ID=75436737

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/120248 WO2021068947A1 (zh) 2019-10-10 2020-10-10 充电桩故障识别的***和方法

Country Status (1)

Country Link
WO (1) WO2021068947A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220252678A1 (en) * 2021-02-08 2022-08-11 Toyota Jidosha Kabushiki Kaisha Abnormality determination apparatus and abnormality determination method
TWI782774B (zh) * 2021-10-29 2022-11-01 拓連科技股份有限公司 電動車充電站之狀態管理方法及系統
WO2023203278A1 (en) * 2022-04-22 2023-10-26 Liikennevirta Oy / Virta Ltd A scalable method to handle faults in a network of electric vehicle charging stations

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100301809A1 (en) * 2009-06-02 2010-12-02 Harjinder Bhade Overcurrent and ground fault protection in a networked charging station for electric vehicles
CN107168299A (zh) * 2017-07-05 2017-09-15 云南电网有限责任公司电力科学研究院 一种充电桩故障诊断处理的方法及***
CN107390056A (zh) * 2017-07-20 2017-11-24 万帮充电设备有限公司 检测充电桩的方法及***
CN109934473A (zh) * 2019-02-28 2019-06-25 深圳智链物联科技有限公司 充电健康指数评分方法、装置、终端设备及存储介质
CN110007170A (zh) * 2019-04-03 2019-07-12 国网山东省电力公司青岛供电公司 充电桩故障自动处理***
CN110232142A (zh) * 2019-06-03 2019-09-13 国家电网有限公司 充电桩故障检测方法、***及终端设备
CN110646699A (zh) * 2019-10-10 2020-01-03 北京嘀嘀无限科技发展有限公司 充电桩故障识别方法、存储介质、充电桩及电子设备
CN111038320A (zh) * 2019-12-31 2020-04-21 北京嘀嘀无限科技发展有限公司 充电桩监控方法、电子设备及存储介质

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100301809A1 (en) * 2009-06-02 2010-12-02 Harjinder Bhade Overcurrent and ground fault protection in a networked charging station for electric vehicles
CN107168299A (zh) * 2017-07-05 2017-09-15 云南电网有限责任公司电力科学研究院 一种充电桩故障诊断处理的方法及***
CN107390056A (zh) * 2017-07-20 2017-11-24 万帮充电设备有限公司 检测充电桩的方法及***
CN109934473A (zh) * 2019-02-28 2019-06-25 深圳智链物联科技有限公司 充电健康指数评分方法、装置、终端设备及存储介质
CN110007170A (zh) * 2019-04-03 2019-07-12 国网山东省电力公司青岛供电公司 充电桩故障自动处理***
CN110232142A (zh) * 2019-06-03 2019-09-13 国家电网有限公司 充电桩故障检测方法、***及终端设备
CN110646699A (zh) * 2019-10-10 2020-01-03 北京嘀嘀无限科技发展有限公司 充电桩故障识别方法、存储介质、充电桩及电子设备
CN111038320A (zh) * 2019-12-31 2020-04-21 北京嘀嘀无限科技发展有限公司 充电桩监控方法、电子设备及存储介质

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220252678A1 (en) * 2021-02-08 2022-08-11 Toyota Jidosha Kabushiki Kaisha Abnormality determination apparatus and abnormality determination method
TWI782774B (zh) * 2021-10-29 2022-11-01 拓連科技股份有限公司 電動車充電站之狀態管理方法及系統
WO2023203278A1 (en) * 2022-04-22 2023-10-26 Liikennevirta Oy / Virta Ltd A scalable method to handle faults in a network of electric vehicle charging stations

Similar Documents

Publication Publication Date Title
WO2021068947A1 (zh) 充电桩故障识别的***和方法
US20220321440A1 (en) Interface Service Function Monitoring Method and System Based on Data Acquisition
CN106548402B (zh) 资源转移监控方法及装置
WO2019006654A1 (zh) 金融自助设备维修派单生成方法、手持终端及电子设备
CN109597398A (zh) 家用电器的故障自动处理方法、装置、设备与存储介质
CN103274272A (zh) 一种电梯综合管理***及电梯综合管理方法
CN110362455B (zh) 一种数据处理方法和数据处理装置
CN110502318A (zh) 事件处理方法、事件处理服务器、存储介质及装置
US11310140B2 (en) Mitigating failure in request handling
CN111831875B (zh) 数据处理方法、装置、设备和存储介质
CN108834040A (zh) 一种考勤信息提醒方法及其设备
CN114978883B (zh) 网络唤醒的管理方法、装置、电子设备及存储介质
CN111835799A (zh) 车辆日志自动获取***及方法
CN112948224A (zh) 一种数据处理方法、装置、终端及存储介质
CN113177845A (zh) 一种基于供应链金融的业务异常监控方法
CN106202542A (zh) 一种生成车辆电池故障派工单的方法及装置
CN108805512A (zh) 一种考勤信息记录方法及其设备、***
CN109739679B (zh) 异常数据处理方法及相关装置
WO2023093299A1 (zh) 设备管理***、方法以及装置
CN115782830A (zh) 电动设备的换电方法、装置、电子设备及存储介质
CN109167958A (zh) 一种监控视频调用方法
CN112202850B (zh) 智能柜售后维护工单***及处理方法
CN115220945A (zh) 基于树莓派的车辆检测设备、方法、车辆及存储介质
CN110348984B (zh) 不同交易渠道下的***数据自动化输入方法及相关设备
CN116010068A (zh) 一种转发任务异常自诊断的方法和装置

Legal Events

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

Ref document number: 20873750

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20873750

Country of ref document: EP

Kind code of ref document: A1