Method and system for determining triggering of a charging contactor
Patent Information
- Application Number
- CN202610501134.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-04-23
- Filing Date
- 2026-04-16
- Publication Date
- 2026-10-23
AI Technical Summary
此外,无法始终保证,车辆确实接收和执行由B2B合作方发起的指令,例如由于缺失的网络连接
Smart Images

Figure CN122957034A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to methods and systems for determining whether a charging mode setting for a vehicle received via an external control interface API triggers an additional switching cycle of a charging contactor included in the vehicle.
[0002] This invention relates to the technical field of charging infrastructure control for electric vehicles, particularly in the cooperation between external charging partners and the vehicle manufacturer's back-end systems. Background Technology
[0003] Within the framework of electrification growth in the transportation sector, remote control technologies via internet-based interfaces (APIs) are becoming increasingly important for the charging process. Here, the so-called remote charging interface takes center stage. This refers to an internet-based programming interface that vehicle manufacturers provide to external partners, typically energy service providers, to remotely influence the charging process of individual vehicles or entire fleets. This always requires the consent of the relevant vehicle users. These interfaces allow charging processes to be started, paused, or scheduled within defined time windows. The goal is to flexibly adapt charging times to economic and grid technology frameworks, for example, by targeting charging during periods of low electricity prices or high renewable energy availability.
[0004] Remote control of a vehicle's charging function involves not only software processes but also the physical components within the vehicle. A central safety-related component is the so-called charging contactor, a mechanical high-voltage switch, which disconnects the battery from the rest of the vehicle's high-voltage system. This contactor disconnects, for example, after the charging process has ended or during a charging pause to prevent potential hazards from high voltage. Such a contactor is designed for a limited number of mechanical operations, or so-called switching cycles, over its lifespan. Each switching cycle corresponds to one opening and subsequent closing of the contacts. Therefore, the number of these cycles must be technically and economically limited to avoid premature wear.
[0005] Control over charging behavior via a remote charging API through a third party directly impacts the lifespan of the charging contactors built into the vehicle. Frequent transitions between charging states (especially through targeted interruptions and restarts of the charging process) can increase the number of switching cycles. Existing solutions count API accesses at the API level within a sliding time window in the form of quotas to avoid overloading the contactors. However, these methods do not directly detect whether API calls actually lead to a switching process. Instead, there are cases where changes in charging settings do not require mechanical disconnection or connection of the contactors. Furthermore, there is no guarantee that the vehicle actually receives and executes instructions initiated by B2B partners, for example, due to a lack of network connectivity. Additionally, the backend itself may not be able to determine with sufficient reliability whether a specific instruction triggered a switching cycle, as existing fleets lack switching cycle counters or corresponding feedback mechanisms.
[0006] For such remote charging functionality to be used reliably and sustainably, it is therefore necessary to be able to determine whether triggered commands result in a switching cycle, even in the event of technical limitations at the back end. This is particularly crucial for charging strategies that integrate existing vehicles into a beneficial power grid without unduly loading the vehicle's physical infrastructure or interfering with safety-related operational aspects. Summary of the Invention
[0007] The objective of this invention is to provide an improved method, particularly a method that, even in the aforementioned circumstances, allows for determining in the backend whether an instruction triggers a switching cycle.
[0008] The task is solved by the technical solution of the independent claim. Advantageous designs of the invention are given in the dependent claims.
[0009] This invention relates to a method for determining whether a charging mode setting for a vehicle received via an external control interface (API) triggers an additional switching cycle of a charging contactor included in the vehicle. The method includes the following steps: receiving the charging mode setting via the external control interface; providing vehicle-specific charging parameters; detecting the current charging state of the vehicle given multiple operating types; simulating the charging state after implementing the received charging mode setting based on the provided vehicle-specific charging parameters; comparing the current state of the vehicle with the simulated state to determine whether there is a transition between the multiple operating types that causes a new additional switching cycle of the charging contactor; and determining the received charging mode setting as an additional switching cycle only in the case of such a transition.
[0010] The present invention also includes a system for determining additional switching cycles for a charging contactor built into a vehicle, the system comprising: a vehicle having a charging contactor; a vehicle-side backend for providing vehicle-specific charging parameters; an external control interface (API) for communicating charging mode settings via an external partner; and a control backend configured to: receive charging mode settings, detect the current charging state of the vehicle, simulate the charging state after implementing the charging mode settings, and determine whether to induce an additional switching cycle based on a comparison between the current charging state and the simulated charging state.
[0011] Receiving charging mode settings via an external control interface preferably refers to receiving control commands from an external system via an external control interface or a defined programming interface (API). Preferably, this involves a communication interface that enables a third-party supplier to send charging commands, such as "charge immediately" or "charge within a time window," to the vehicle manufacturer's backend.
[0012] Providing vehicle-specific charging parameters preferably includes retrieving and storing information such as the current state of charge, target state of charge, connection to the charging station, and, if necessary, the planned departure time. Preferably, this information is sourced from the vehicle's rear end or from the fleet system and is kept up-to-date.
[0013] Detecting the current charging state of a vehicle given multiple operating types preferably means clarifying the system state using combined parameters, such as charging mode, charging time window, and the actual charging process. "Multiple operating types" preferably refers to distinguishable states on the system side, such as active immediate charging, active time window charging, and inactive time window charging. The advantage is that state transitions can be associated with potential physical switching processes.
[0014] The simulation of the charging state after implementing the received charging mode setting preferably includes a hypothetical assessment of the impact of commands triggered by the charging mode setting on charging behavior. Preferably, the expected future operating state is calculated using current parameters. The advantage of this technique is that charging behavior can be predicted without actual intervention in vehicle behavior.
[0015] In comparing the vehicle’s current state with the simulated state, it is preferably determined whether an intentional charging mode switch occurs during the transition between defined operating types.
[0016] The received charging mode setting is preferably determined as an additional switching cycle only when there is a transition that triggers the switching cycle. Preferably, the counting of the switching process is only initiated when a transition to a state that physically requires the charging contactor to be open and closed is performed. The term "switching cycle" preferably refers to one complete mechanical opening and closing process of the charging contactor, which serves as a safety device between the battery and the high-voltage system. An advantage is that wear on the mechanical components can be controlled and limited by external control commands.
[0017] Charging mode settings refer to configurations transmitted via an external control interface to the vehicle or its rear end for controlling the vehicle's charging behavior. Such settings may include, for example, an "Immediate Charging" mode in which the vehicle begins charging immediately, or a "Time Window" mode in which charging only occurs within a defined time period. Charging mode settings may also optionally include parameters such as charging time windows or target state of charge.
[0018] Vehicle-specific charging parameters include the vehicle's technical information and state-related information, which is considered to evaluate current or simulated charging behavior. This information specifically includes the State of Charge (SOC), Target-SOC, connection status to the charging station, and, if necessary, the configured departure time.
[0019] The term switching cycle refers to the mechanical operation of a charging contactor built into a vehicle, in which the charging contactor transitions from an on state to an off state once and then back to an on state, or vice versa. Switching cycles typically occur at the start or end of charging, particularly during transitions between charging states.
[0020] An additional switching cycle exists when a change in the vehicle's charging behavior, triggered by a change in the charging mode setting, causes a new mechanical disconnection and connection process in the charging contactor, a process that would not occur without a change in the charging mode.
[0021] An external control interface refers to a programming interface (API) configured for vehicle manufacturers, through which authorized external partners, particularly energy suppliers or fleet operators, can set vehicle charging settings for individual vehicles or groups of vehicles.
[0022] The term "vehicle" includes any system used to transport people or goods on roads, rails, water, or in the air, such as cars, vans, buses, motorhomes, and motorcycles. The vehicle can be driven by an internal combustion engine, a hybrid drive system, or a purely electric drive system. Public or private charging stations can utilize this method. Any battery suitable for electric or hybrid applications can be used, such as a lithium-ion battery, also known as a lithium-ion accumulator or lithium-ion battery. The terms "battery" and "accumulator" are equivalent to each other.
[0023] On the other hand, it is proposed that vehicle-specific charging parameters include the vehicle's state of charge, target state of charge, connection status with the charging station, and / or the configured departure time.
[0024] Vehicle-specific charging parameters preferably include the state of charge (SOC), which describes the current energy stored in the vehicle's battery relative to its total capacity. Also known as the State of Charge (SOC), SOC is preferably given as a percentage and used as a central parameter for determining current energy demand. Another parameter is preferably a target SOC, which specifies the state of charge the vehicle should be charged to, a value configurable on the driver's or system side. This enables demand-driven charging plans. The connectivity status with the charging station preferably indicates whether the vehicle is physically connected to the charging infrastructure, a prerequisite for any charging process. This information is technically advantageous because it provides context for evaluating charging instructions and reduces the occurrence of unexecutable instructions. Furthermore, the configured departure time preferably represents the time when the user plans to restart the vehicle. Such timing allows for charging times optimized for grid load and electricity prices, thus improving energy efficiency and user-friendliness.
[0025] On the other hand, it is proposed that the charging mode setting be ignored when the vehicle is not connected to a charging station and / or the state of charge corresponds to at least the target state of charge.
[0026] When the vehicle is not connected to a charging station, the charging mode setting is preferably ignored because charging is technically impossible in this situation. The connection status preferably describes the physical contact between the vehicle and the charging point, and is therefore crucial to the validity of the charging mode command. Another case of ignoring this setting is preferably given when the current state of charge (SOC) at least corresponds to the target SOC, since there is no direct charging requirement in this case. These conditions prevent unnecessary control commands that would be ineffective and help protect system resources and mechanical components such as charging contactors. The SOC and target SOC are used here as logical comparison parameters to assess the necessity of the charging process.
[0027] On the other hand, it is proposed that multiple operating types include at least the following states: charging in "immediate charging" mode, in which the vehicle is currently being charged; charging in "time window charging" mode within an active charging time window, in which the vehicle is being charged; and not charging in "future time window" mode with a charging time window in the future, in which the vehicle is not currently being charged.
[0028] The various operating types preferably include three central states: In the immediate charging mode, the vehicle is being charged, particularly regardless of time constraints. This mode enables direct energy input and is preferably useful in situations with short-term energy demand. The "time window charging" mode, within an activated charging time window, preferably describes time-controlled charging activity, in which the vehicle is charged only during a configured time period. This operating type is preferably suitable for load transfer beneficial to the power grid. In the "future time window" mode, the set time period is in the future, and the vehicle is not being charged at present. This state is preferably identified by a planned but not yet started charging process. Here, there is a technical advantage to the possibility of planning control commands in advance without triggering immediate system intervention. The distinction between these three operating types allows for precise assessment of whether a mechanical switching process is required when changing charging modes.
[0029] On the other hand, it is proposed that an additional switching cycle be determined only when transitioning from the "Instant Charging" mode or from the activated "Time Window" mode to the "Future Time Window" mode which has a charging start in the future.
[0030] Preferably, additional switching cycles are determined only when transitioning from an active charging mode (such as "immediate charging" or within an active window) to an inactive mode with a future charging time window. In this case, the vehicle first ends the active charging process and preferably disconnects the charging contactor, thereby triggering a mechanical switching process. Therefore, only transitions associated with the switching cycle are counted. The term "switching cycle" preferably refers to a complete mechanical disconnection and subsequent reconnection of an electrical high-voltage contactor connected between the battery and the charging infrastructure for safety reasons. Selectively considering these transitions reduces unnecessary counting and improves the accuracy of predictions regarding the lifespan of the charging contactor.
[0031] On the other hand, it is proposed that the simulation of charging state includes the prediction of the vehicle's charging decision after applying and / or accepting the charging mode setting.
[0032] The simulation of charging states preferably includes software-based prediction of charging decisions, which the vehicle makes after applying and / or receiving the transmitted charging mode settings. Preferably, this involves calculating whether and when the vehicle anticipates starting or ending the charging process, given valid charging parameters. The advantage is that the system can assess early on whether control instructions will lead to physically relevant events, particularly switching cycles. The term "simulation" preferably refers to a method for modeling future system behavior based on available input parameters without necessarily triggering real-world actions on the vehicle.
[0033] On the other hand, it is proposed that a count is set only for the following charging modes, for which the transition of the trigger switching cycle is identified by simulation.
[0034] Preferably, the counting is set only for charging modes in which the transition, as confirmed by the aforementioned simulation, is associated with additional switching cycles of the charging contactor. Preferably, this selective detection allows the identification of control events related to switching to focus on actual action correlations and avoids over-counting of technically irrelevant commands. This enables a more accurate and wear-oriented assessment of actual mechanical loads. The term "transition triggering a switching cycle" preferably refers to a change in system state in which the disconnection and / or connection of the high-voltage contactor is indeed necessary.
[0035] In another aspect, it is proposed that the method be used to controllably limit the switching cycle caused by external control commands.
[0036] The method is preferably used to selectively monitor and limit the number of switching cycles caused by external control commands. Preferably, this ensures that mechanical components, such as charging contactors, are not overloaded due to frequent load switching. Advantageously, it extends the lifespan of safety-critical hardware while maintaining the functionality of the external charging interface.
[0037] On the other hand, it is proposed to record the decision regarding the existence of a transition that triggers a switching cycle in the charging event database.
[0038] The decision of whether a transmitted instruction triggered a transition in a switching cycle is preferably recorded in a charging event database. The database preferably contains structured entries listing the time, type of control instruction, and simulation results. The advantage lies in the uninterrupted traceability of charging events and the possibility of performing analyses for system load or regulatory purposes.
[0039] On the other hand, it is proposed to assign a vehicle identifier to each counted switching cycle, and the vehicle specifically manages the accumulated count.
[0040] Each counted switching cycle is preferably assigned a distinct vehicle identifier to enable vehicle-specific tracking of switching loads. The vehicle identifier is preferably a VIN (Vehicle Identification Number) or an internal ID. The data listed thus is preferably aggregated in a cumulative counter for each vehicle. This opens up the possibility of accurately monitoring the lifespan limits of individual vehicles and, if necessary, deriving vehicle-specific measures.
[0041] On the other hand, it is proposed that the charging plan operator be notified if the predefined switching cycle limit for the vehicle is exceeded.
[0042] When the predefined switching cycle limit for the vehicle is exceeded, the operator responsible for the charging plan or the back-end operator is preferably notified automatically. The notification is preferably delivered electronically through a monitoring system or messaging system.
[0043] On the other hand, it is proposed to use charging cycle detection for settlement of API usage by external partners.
[0044] Preferably, the detection of charging cycles is also used for settlement of API usage by external partners. Here, the control commands that trigger switching cycles are preferably used only as the basis for settlement, enabling wear-oriented compensation for external intervention. The term "API usage" preferably refers to the total number of valid external control commands that are passed through a defined interface and executed in the backend.
[0045] The present invention also includes a computer program product comprising instructions that, when the method is performed by a computer, cause the computer to perform the method.
[0046] The present invention further includes a computer-readable medium on which a computer program product is stored. Attached Figure Description
[0047] Embodiments of the present invention are shown in the accompanying drawings and described in more detail below. Unless otherwise specified, the same reference numerals are used for the same and equivalent elements.
[0048] In the picture:
[0049] Figure 1 A schematic flowchart illustrating an embodiment of the method is provided.
[0050] Figure 2 A schematic block diagram illustrating an embodiment of the system is shown.
[0051] Figure 3 A schematic flowchart illustrating an exemplary charging process plan, and
[0052] Figure 4 This diagram illustrates the switching between different operating types. Detailed Implementation
[0053] Figure 1 The method according to a first embodiment of the invention is illustrated with a schematic flowchart. The method is also referred to... Figure 2 The explanation, the stated Figure 2 A schematic block diagram of a system 200 according to one embodiment of the invention is shown. The method is used to determine whether a charging mode setting for a vehicle 202 received via an external control interface API 201 triggers an additional switching cycle of the charging contactor included in the vehicle 202.
[0054] In the first step S1, a charging mode setting is received via an external control interface 201. In the first step S2, vehicle-specific charging parameters 204 are provided. In the first step S3, the current charging state of the vehicle 202 is checked considering various operating types. In the first step S4, after implementing the received charging mode setting, a charging state is simulated based on the provided vehicle-specific charging parameters 204. In the first step S5, the vehicle 202 compares the current state with the simulated state to determine if there is a transition between the various operating types that causes a new additional switching cycle for the charging contactor, and only in the case of such a transition, in step S6, the received charging mode setting is determined as an additional switching cycle.
[0055] Figure 2 The system 200 shown includes a vehicle 202 with a charging contactor 206, configured to determine additional switching cycles for the charging contactor 206 built into the vehicle 202. Furthermore, the system 200 includes a vehicle-side backend 208 for providing vehicle-specific charging parameters 204 and an external control interface (API) 206 for communicating charging mode settings via an external partner. Additionally, the system 200 includes a control backend 210 configured to receive charging mode settings, detect the vehicle's current charging state, simulate the charging state after implementing the charging mode settings, and determine whether to initiate additional switching cycles based on a comparison between the current state and the simulated state. Preferably, charging output control 212 is performed via mobile radio communication with the vehicle 202.
[0056] Figure 3A flowchart is shown to illustrate an exemplary implementation of a charging-plan-based control method for a vehicle using an external programming interface (API). It illustrates how vehicle 202 initiates a charging process after being connected to a charging station (vehicle plug-in), a process comprised of multiple control commands, or charging commands. The charging process continues until a target state of charge (SOC) is reached or until the departure time is reached. A total of five different control commands are shown, executed in a staggered manner.
[0057] The horizontal axis represents the time process, beginning with Vehicle Plug-In and ending with the planned Departure Time. The desired charging plan is shown along this time axis, with charging phases characterized by successive steps.
[0058] exist Figure 3 The lower area displays control commands (“Commands”) numbered 0 to 5. Each command is associated with a specific function, such as setting a specific charging mode when stopping or starting the charging process. Command 0 (“Get”) is used to retrieve vehicle-specific parameters and for initial calculation of the charging plan. Commands 1 and 3 (“Stop via Charging Window”) each set a charging time window to interrupt the charging process. Commands 2 and 4 (“Start via Immediate Charge”) activate immediate charging by switching to “Immediate Charge” mode. Command 5 (“Stop+”) is used to reset the charging settings to their previous values.
[0059] Figure 3 This further illustrates when individual commands should be executed to achieve the desired charging process. This specifically includes the recurring transition between the "time window" and "immediate charging" modes, related to the State of Charge (SOC) and the planned start time. New charging time windows are added during charging interruptions, while the command for immediate charging is sent at the start of charging. This ensures that the target SOC is reached at the planned time. At the end of the charging plan, the original settings are re-established via a "Restore" command.
[0060] The sequence illustrates how external partners can implement dynamic charging behavior with multiple charging and pause phases via defined API commands without triggering unnecessary switching cycles within the vehicle. The combination of time window control and immediate charging is used to generate grid-friendly, cost-optimized, and vehicle-integrated charging characteristics (Ladeprofil).
[0061] Figure 4 As shown, the various operating types include at least the following states: namely, in "Instant Charging" (… Figure 4 Charging in the "Imm" mode (abbreviated as "Imm"), currently charging vehicle 202 in the "Immediate Charging" mode; "Time Window Charging" within the activated charging time window ( Figure 4 Charging in the "TW-in" mode (abbreviated as "TW-in"), charging vehicle 202 in the "time window charging" mode; and a "future time window" (with a charging time window in the future) mode. Figure 4 In the "TWfut" mode (abbreviated as "TWfut"), charging is not in progress, and in the "future time window" mode, vehicle 202 is not currently being charged. This is derived from three different operating types. Figure 4 The diagram illustrates nine possible transitions between different operating types. Only when there is a transition from "Instant Charge" (…) Figure 4 The abbreviation is "Imm" in Chinese, or from the "time window" ( Figure 4 The mode activated by "TW-in" (abbreviated as "TW-in") is a "future time window" that begins charging in the future. Figure 4 The additional switching cycle is determined only during the transition in the (abbreviated as "TW-fut") mode.
[0062] The features described in the embodiments of the present invention with reference to the present invention may also exist in other embodiments of the present invention, unless otherwise stated or are not feasible by themselves for technical reasons.
[0063] Figure Labels
[0064] 200 system
[0065] 201 External Control Interface
[0066] Vehicle 202
[0067] 204 Vehicle-Specific Charging Parameters
[0068] 206 Charging Contactor
[0069] Rear end of vehicle 208
[0070] 210 Control Backend
[0071] 212 Charging Output Control
[0072] S1 Method Steps
[0073] S2 Method Steps
[0074] S3 Method Steps
[0075] S4 Method Steps
[0076] S5 Method Steps
[0077] S6 Method Steps
Claims
1. A method for determining whether a charging mode setting for a vehicle (202) received via an external control interface API (201) triggers an additional switching cycle of a charging contactor (206) included in the vehicle (202), the method comprising the steps of: - Receive (S1) charging mode setting via external control interface (201), - Provide (S2) vehicle-specific charging parameters (204). - Detect (S3) vehicle (202) in light of the current charging status of various operating types, - Simulate (S4) the charging state after implementing the received charging mode setting based on the provided vehicle-specific charging parameters (204). - Compare the current charging state of vehicle (202) (S5) with the simulated charging state to determine whether there is a transition between the plurality of operating types that causes a new additional switching cycle of the charging contactor (206), and only in the case of such a transition, - The received charging mode setting is determined (S6) as an additional switching cycle.
2. The method according to claim 1, wherein, Vehicle-specific charging parameters (204) include the vehicle's state of charge, target state of charge, connection status with the charging station, and / or the configured departure time. Wherein, when the vehicle (202) is not connected to the charging pile and / or the state of charge corresponds at least to the target state of charge, the charging mode setting may be ignored.
3. The method according to any one of the preceding claims, wherein, The various operating types include at least the following states: a) Charging in "Instant Charging" mode, in which the vehicle (202) is currently being charged. b) Charging in "Time Window Charging" mode within an activated charging time window, in which vehicle (202) is being charged, and c) No charging in a “future time window” mode with a charging time window in the future, in which the vehicle (202) is not currently being charged.
4. The method according to any one of the preceding claims, wherein, Additional switching cycles are determined only when there is a transition from "Instant Charging" mode or from an active "Time Window" mode to a "Future Time Window" mode with charging starting in the future; and / or The simulation of charging status includes the prediction of the charging decision of the vehicle (202) after applying and / or accepting the charging mode setting.
5. The method according to any one of the preceding claims, wherein, The count is set only for the following charging modes, for which the transition triggering the switching cycle was identified through simulation; and / or The method described above is used to controllably limit the switching cycle caused by the use of external control commands.
6. The method according to any one of the preceding claims, wherein, Record decisions regarding transitions that trigger switching cycles in the charging event database; and / or Each counted switching cycle is assigned a vehicle identifier, and the vehicle specifically manages the accumulated count.
7. The method according to any one of the preceding claims, wherein, Notify the charging plan operator if the predefined switching cycle limit for the vehicle (202) is exceeded; and / or Among these measures, charging cycle detection will be used for settlement of API usage with external partners.
8. A system (200) for determining additional switching cycles of a charging contactor included in a vehicle (202), the system comprising: - Vehicle (202) with charging contactor (206). - Vehicle-side rear end (208) for providing vehicle-specific charging parameters (204). - External control interface API (201) for setting the charging mode via communication with external partners. - Control backend (210), the control backend is configured to: receive charging mode setting, detect the current charging state of the vehicle (202), simulate the charging state after the charging mode setting is implemented, and determine whether to cause an additional switching cycle based on a comparison between the current charging state and the simulated charging state.
9. A computer program product having program code, which, when implemented on a computer, causes the method according to any one of claims 1 to 7, wherein, The program code is stored on a non-volatile digital storage medium.
10. A computer-readable medium on which a computer program product according to the preceding claim is stored.