METHOD AND SYSTEM FOR DETERMINING A CHARGE ACTIVATION

Abstract

The invention relates to a method for determining whether a charging mode setting for a vehicle (200) 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: receiving (S1) a charging mode setting via the external control interface (201), providing (S2) vehicle-specific charging parameters (204), acquiring (S3) a current state of charge of the vehicle (202) with respect to several operating modes, simulating (S4) a state of charge after execution of the received charging mode setting based on the provided vehicle-specific charging parameters (204), comparing (S5) the current and the simulated state of the vehicle (202) to determine whether a transition between the several operating modes occurs that causes a new additional switching cycle of the charging contactor (206), and only in the case of such a transition,Determine (S6) the received charging mode setting as an additional switching cycle.

Description

[0001] The disclosure relates to a method and a system for determining whether a charging mode setting received through an external control interface, API, for a vehicle triggers an additional switching cycle of a charging contactor included in the vehicle.

[0002] The present invention relates to the technical field of charging infrastructure control for electric vehicles, in particular in the interaction between external charging partners and the backend systems of vehicle manufacturers.

[0003] Publication CN 2 14 874 320 U discloses an AC charging station control system comprising a microprogrammed control unit (MCU) main control chip. The MCU is connected via the charging port to the temperature circuit at the interface to monitor over-temperature protection at the interface.

[0004] As the transport sector becomes increasingly electrified, technologies for remotely controlling charging processes via internet-based interfaces (APIs) are gaining importance. Remote Charging Interfaces (RVIs) play a central role in this development. These are internet-based programming interfaces that vehicle manufacturers provide to external partners, typically energy service providers, to remotely influence the charging processes of individual vehicles or entire fleets. This always requires the consent of the respective vehicle users. These interfaces allow charging processes to be started, paused, or scheduled within specific time windows. The goal is to flexibly adapt charging times to economic and grid conditions, for example, by targeting charging during periods of low electricity prices or high availability of renewable energy.

[0005] Remote control of a vehicle's charging functions is not solely a software process, but also affects physical components within the vehicle itself. A key safety-relevant component is the charging contactor, a mechanical high-voltage switch that electrically isolates the battery from the rest of the vehicle's high-voltage system. The contactor opens, for example, after a charging process is complete or during a charging break to prevent potential hazards from high voltage. Such contactors are designed for a limited number of mechanical actuations, known as switching cycles, over their service life. Each switching cycle consists of the contact opening and then closing. The number of these cycles must therefore be limited for technical and economic reasons to prevent premature wear.

[0006] Controlling charging behavior by third parties via the Remote Charging API thus has a direct impact on the service life of the charging contactors installed in the vehicle. Frequent switching between charge states, especially through deliberate interruptions and resumptions of the charging process, can increase the number of switching cycles. Previous solutions rely on access counting at the API level in the form of quota regulations within sliding time windows to prevent excessive stress on the contactors. However, these methods do not directly record whether an API call actually resulted in a switching operation. In fact, there are cases where changes to the charging settings do not require any mechanical opening or closing of the contactor. Furthermore, it is not always guaranteed that a command initiated by the B2B partner will actually be received and executed by the vehicle, for example, due to a lack of internet connectivity.Even in the backend itself, there is currently no way to determine with sufficient certainty whether a specific command has triggered a switching cycle, as there are no switching cycle counters or corresponding feedback mechanisms in the existing fleet.

[0007] For reliable and sustainable use of such remote charging functionalities, it is therefore necessary to be able to determine, even under the given technical limitations in the backend, whether a triggered command has led to a switching cycle. This is particularly crucial for integrating existing vehicles into grid-supportive charging strategies without placing undue strain on the vehicles' physical infrastructure or interfering with safety-relevant operating areas.

[0008] The object of the present invention is to provide an improved method, in particular one that can determine in the backend, despite the aforementioned circumstances, whether a command triggers a switching cycle.

[0009] This problem is solved by the subject matter of the independent claims. Advantageous embodiments of the invention are specified in the dependent claims.

[0010] The invention relates to a method for determining whether a charging mode setting received via an external control interface (API) for a vehicle triggers an additional switching cycle of a charging contactor included in the vehicle. The method comprises the steps of: receiving a charging mode setting via the external control interface, providing vehicle-specific charging parameters, acquiring a current state of charge of the vehicle with regard to several operating modes, simulating a state of charge after execution of the received charging mode setting based on the provided vehicle-specific charging parameters, comparing the current and the simulated state of the vehicle to determine whether a transition between the several operating modes occurs that causes a new additional switching cycle of the charging contactor, and only in the case of such a transition, determining the received charging mode setting as an additional switching cycle.

[0011] The invention also includes a system for determining additional switching cycles of a charging contactor installed in a vehicle, comprising: a vehicle with a charging contactor, a vehicle-side backend for providing vehicle-specific charging parameters, an external control interface (API) for communicating charging mode settings by external partners, a control backend configured to receive charging mode settings, detect the current state of charge of the vehicle, simulate the state of charge after execution of the charging mode setting, and determine, based on the comparison of the current and the simulated state, whether an additional switching cycle is caused.

[0012] Receiving a charging mode setting via the external control interface preferably refers to the input of a control command from an external system via an external control interface or a defined application programming interface (API). Preferably, this is a communication interface that allows third-party providers to send charging commands such as "instant charging" or "time-window charging" to the backend of a vehicle manufacturer.

[0013] Providing vehicle-specific charging parameters preferably includes retrieving and storing information such as the current state of charge, a target state of charge, the connection to a charging station, and, if applicable, a planned departure time. Preferably, this data originates from the vehicle's backend or from a fleet management system and is kept up to date.

[0014] Capturing the current state of charge of the vehicle with regard to multiple operating modes preferably means that the system state is interpreted based on combined parameters such as charging mode, charging time window, and the actual charging process. The "multiple operating modes" preferably refer to system-distinguishable states such as active instant charging, active time-window charging, and inactive time-window charging. The advantage lies in the fact that state changes can be associated with potential physical switching operations.

[0015] The simulation of a state of charge after execution of the received charging mode setting preferably includes a hypothetical evaluation of the effect of a command triggered by the charging mode setting on the charging behavior. Preferably, an expected future operating state is calculated using the current parameters. A technical advantage is that the charging behavior can be anticipated without requiring any actual intervention in the vehicle's behavior.

[0016] When comparing the current and simulated state of the vehicle, it is preferably determined whether the intended change in charging mode results in a transition between the defined operating modes.

[0017] Determining the received charging mode setting as an additional switching cycle preferably only occurs in the case of a transition that triggers a switching cycle. Preferably, this only initiates a count of the switching process when a change to a state occurs that physically requires the opening and closing of a charging contactor. The term "switching cycle" preferably refers to a complete mechanical opening and closing process of a charging contactor that functions as a safety device between the battery and the high-voltage system. The advantage lies in the ability to control and limit wear on mechanical components through external control commands.

[0018] The charging mode setting refers to a setting transmitted via an external control interface to a vehicle or its backend to control the vehicle's charging behavior. Such a setting can include, for example, "Immediate Charging" mode, in which the vehicle begins charging immediately, or a "Time Window" mode, in which charging only occurs within a defined time interval. The charging mode setting can optionally also include parameters such as charging time windows or target charge levels.

[0019] Vehicle-specific charging parameters comprise technical and condition-dependent information about a vehicle, which are used to assess current or simulated charging behavior. This includes, in particular, the state of charge (SOC), the target state of charge (Target SOC), the connection status to a charging station, and, if applicable, a configured departure time.

[0020] The term switching cycle refers to the mechanical actuation of a charging contactor installed in a vehicle, in which it transitions from a closed to an open state and then back to the closed state, or vice versa. Switching cycles typically occur at the beginning or end of charging, especially when changing between charge states.

[0021] An additional switching cycle occurs when a change in the vehicle's charging behavior, triggered by a charging mode setting, causes a new mechanical opening and closing process of the charging contactor that would not have occurred without the change in charging mode.

[0022] External control interface refers to a programming interface (API) assigned to the vehicle manufacturer, through which authorized external partners, in particular energy suppliers or fleet operators, can set vehicle charging settings for individual vehicles or vehicle groups.

[0023] The term "vehicle" encompasses any system for transporting people and goods on roads, e.g., cars, trucks, buses, motorhomes, motorcycles, on rails, on water, or in the air. The vehicle can be powered by an internal combustion engine, a hybrid drive, or a purely electric drive. Public or private charging stations can utilize the process. Any battery suitable for an electric or hybrid application, e.g., a lithium-ion battery, also called a lithium-ion accumulator or lithium battery, can be used. The terms "battery" and "accumulator" are synonymous.

[0024] In another aspect, it is proposed that the vehicle-specific charging parameters include a state of charge, a target state of charge, a connection status to a charging station and / or a configured departure time of the vehicle.

[0025] The vehicle-specific charging parameters preferably include a state of charge (SOC) that indicates the current energy content of the vehicle battery relative to its total capacity. The SOC is preferably expressed as a percentage and serves as a key parameter for determining the current energy demand. Another parameter is preferably the target SOC, which defines the state of charge to which the vehicle should be charged. This value can be configured by the driver or the system. This enables demand-based charging planning. The connection status to a charging station preferably indicates whether the vehicle is physically connected to a charging infrastructure, which is a prerequisite for any charging process. This information is technically advantageous because it provides the context for evaluating charging commands and reduces the occurrence of commands that cannot be executed.Furthermore, the configured departure time preferably refers to the time at which the user plans to put the vehicle back into operation. This time specification allows for the optimization of charging times with regard to grid load and electricity prices, thus improving energy efficiency and user-friendliness.

[0026] Another aspect is proposed: charging mode settings should be ignored if the vehicle is not connected to a charging station and / or the state of charge is at least equal to the target state of charge.

[0027] Charging mode settings are preferably ignored when the vehicle is not connected to a charging station, as charging would be technically impossible under these circumstances. The connection status preferably reflects the physical contact between the vehicle and the charging point and is therefore crucial for the effectiveness of a charging mode command. Another preferred scenario for ignoring the settings is when the current state of charge is at least equal to the target state of charge, as there is no immediate charging requirement in this case. This condition prevents unnecessary control commands that would have no effect and helps to conserve system resources and mechanical components such as the charging contactor. The state of charge and target state of charge preferably serve as logical comparison parameters for assessing the necessity of a charging process.

[0028] In another aspect, it is proposed that the multiple operating modes include at least the following states: charging in an "instant charging" mode, in which the vehicle is currently being charged; charging in a "time window charging" mode within an active charging time window, in which the vehicle is currently being charged; and not charging in a "future time window" mode with a charging time window in the future, in which the vehicle is not currently being charged.

[0029] The multiple operating modes preferably comprise three central states: In "Instant Charging" mode, the vehicle is being charged immediately, particularly regardless of time specifications. This mode enables an immediate energy supply and is particularly useful for short-term energy demands. The "Time Window Charging" mode within an active charging window preferably describes a time-controlled charging activity in which the vehicle only charges within a configured time interval. This operating mode is preferably suitable for grid-friendly load shifting. In "Future Time Window" mode, the set charging interval lies in the future, and the vehicle is not currently charging. This state is preferably characterized by planned but not yet started charging processes. A technical advantage here is the ability to plan control commands in advance without triggering immediate system interventions.The distinction between these three operating modes allows for a precise assessment of whether a change in charging mode results in a transition that necessitates a mechanical switching process.

[0030] In another aspect, it is proposed that an additional switching cycle is only determined if there is a transition from the "instant charging" mode or from the active "time window" mode to a "future time window" mode with charging starting in the future.

[0031] An additional switching cycle is preferably only determined when there is a transition from an active charging mode, such as "instant charging" or "time window" within an active window, to a passive mode with a future charging time window. In this case, the vehicle first terminates the active charging process and preferably opens the charging contactor, thereby triggering a mechanical switching operation. Thus, only transitions actually relevant to a switching cycle are counted. The term "switching cycle" preferably refers to a complete mechanical process of opening and subsequently closing an electrical high-voltage contactor, which is connected between the battery and the charging infrastructure for safety reasons. The selective consideration of transitions reduces unnecessary counts and improves the predictive accuracy for the charging contactor's service life.

[0032] In another aspect, it is proposed that simulating the state of charge includes anticipating a charging decision of the vehicle after application and / or acceptance of the charging mode setting.

[0033] Simulating the state of charge preferably involves software-based anticipation of a charging decision that the vehicle would make after applying and / or accepting a transmitted charging mode setting. This preferably involves calculating, based on valid charging parameters, whether and when the vehicle is likely to begin or end a charging process. The advantage is that the system can assess early on whether a control instruction would lead to a physically relevant event, in particular a switching cycle. The term "simulation" preferably refers to a method for modeling future system behavior based on available input variables, without requiring any actual action to be triggered on the vehicle.

[0034] In another aspect, it is proposed that only charging mode settings for which a switching cycle-triggering transition has been identified by the simulation should be counted.

[0035] Preferably, only those charging mode settings are counted where the aforementioned simulation detects a transition associated with an additional switching cycle of the charging contactor. This selective detection preferably allows the determination of switching-relevant control events to be focused on actual interactions and avoids excessive counting of technically irrelevant commands. This enables a more precise and wear-oriented assessment of the actual mechanical stress. The term "switching cycle-triggering transition" preferably refers to a system state change that actually necessitates the opening and / or closing of a high-voltage contactor.

[0036] In another aspect, it is proposed that the procedure be used to control and limit the switching cycles caused by external control commands.

[0037] This method is preferably used to monitor and limit the number of switching cycles caused by external control commands. This preferably ensures that mechanical components such as the charging contactor are not overloaded by frequent load changes. An advantage is the increased service life of safety-critical hardware while simultaneously maintaining the functionality of external charging interfaces.

[0038] In another aspect, it is proposed that the decision regarding the presence of a switching cycle-triggering transition be documented in a charging event database.

[0039] The decision as to whether a transmitted control command has triggered a switching cycle transition is preferably documented in a charging event database. This database preferably contains structured entries that record the time, type of control command, vehicle identifier, and the simulation result. The advantage lies in the seamless traceability of charging events and the ability to perform analyses for system stress or for regulatory purposes.

[0040] In another aspect, it is proposed that each counted switching cycle be assigned a vehicle identifier, and that a cumulative count be managed on a vehicle-specific basis.

[0041] Each counted switching cycle is preferably assigned a unique vehicle identifier to track the switching load on a vehicle-specific basis. This vehicle identifier can preferably be a VIN (Vehicle Identification Number) or an internal ID. The data thus recorded is preferably aggregated in a cumulative counter for each vehicle. This makes it possible to precisely monitor the service life limits of individual vehicles and, if necessary, to derive vehicle-specific measures.

[0042] Another aspect proposed is that if a predefined switching cycle limit for a vehicle is exceeded, a notification should be sent to the charging planning operator.

[0043] If a predefined switching cycle limit for a vehicle is exceeded, a notification is preferably automatically sent to a charging planning manager or backend operator. This notification is preferably sent electronically via a monitoring or messaging system.

[0044] Another aspect proposed is that the charging cycle recording be used for billing API usage to an external partner.

[0045] The recording of charging cycles is preferably also used for billing API usage to an external partner. Preferably, only control commands that trigger switching cycles serve as the basis for billing, thus enabling wear-based compensation for external interventions. The term "API usage" preferably refers to the sum of valid external control commands that were input via a defined interface and executed in the backend.

[0046] The invention also includes a computer program product comprising instructions which, when the method is executed by a computer, cause the computer to execute the method.

[0047] The invention also includes a computer-readable medium on which the computer program product is stored.

[0048] Exemplary embodiments of the invention are illustrated in the figures and are described in more detail below. Unless otherwise specified, the same reference numerals are used for identical and equivalently acting elements.

[0049] They show: Fig. 1 a schematic flowchart of an exemplary embodiment of the method, Fig. 2 a schematic block diagram of an embodiment of the system, Fig. 3 a schematic flowchart of an exemplary loading process plan, and Fig. 4 a schematic representation of changes between different operating modes.

[0050] In Fig. Figure 1 illustrates the method according to the invention in a first embodiment by means of a schematic flowchart. The method is also referred to in Fig. Figure 2 explains, which shows a schematic block diagram of a system 200 according to the invention in one embodiment. The method serves to determine whether a charging mode setting received by an external control interface, API, 201 for a vehicle 202 triggers an additional switching cycle of a charging contactor included in the vehicle 202.

[0051] In a first step S1, a charging mode setting is received via the external control interface 201. In a first step S2, vehicle-specific charging parameters 204 are provided. In a first step S3, the current state of charge of the vehicle 202 is determined with regard to several operating modes. In a first step S4, a state of charge is simulated after execution of the received charging mode setting based on the provided vehicle-specific charging parameters 204. In a first step S5, the current and the simulated state of the vehicle 202 are compared to determine whether a transition between the several operating modes occurs that causes a new additional switching cycle of the charging contactor. Only in the case of such a transition, in a step S6, the received charging mode setting is determined as an additional switching cycle.

[0052] The in Fig. System 200, shown in Figure 2, which is configured to determine additional switching cycles of a charging contactor 206 installed in the vehicle 202, comprises the vehicle 202 with a charging contactor 206. System 200 also includes a vehicle-side backend 208 for providing the vehicle-specific charging parameters 204 and an external control interface (API) 206 for communicating charging mode settings with external partners. Furthermore, System 200 includes a control backend 210 configured to receive charging mode settings, detect the current state of charge of the vehicle, simulate the state of charge after the charging mode setting has been executed, and determine, based on a comparison of the current and simulated states, whether an additional switching cycle is required. Charging control 212 is preferably carried out via mobile communication with the vehicle 202.

[0053] The Fig. Figure 3 shows a flowchart illustrating an example implementation of a charging plan-based control procedure for a vehicle using an external application programming interface (API). It shows how the vehicle 202, after connecting to the charging station (vehicle plug-in), executes a charging process consisting of several control commands or charging commands. The charging process continues until the target state of charge (SOC) is reached or until a departure time is reached. A total of five different control commands are shown, which are executed sequentially.

[0054] The horizontal axis represents the timeline, starting with the vehicle plug-in and ending with the planned departure time. Along this timeline, the desired charging plan is shown, with charging phases symbolized by solid bars.

[0055] In the lower area of ​​the Fig. Three control commands, numbered from 0 to 5, are shown. Each command is associated with a specific function, such as stopping or starting the charging process by setting specific charging modes. Command 0 ("Get") is used to retrieve vehicle-specific charging parameters and to initially calculate the charging plan. Commands 1 and 3 ("Stop via Charging Window") each set a charging window to interrupt the charging process. Commands 2 and 4 ("Start via Immediate Charge") activate immediate charging by switching to "Immediate Charging" mode. Command 5 ("Stop+") is used to reset the charging settings to their previous values.

[0056] Fig. Section 3 further shows at which times the individual commands are to be executed to implement a desired charging profile. This includes, in particular, repeated transitions between the "Time Window" and "Immediate Charging" modes, depending on the state of charge (SOC) and the planned departure time. A new charging window is inserted whenever charging is interrupted, while a command for immediate charging is sent when charging begins. This ensures that the target state of charge (Target SOC) is reached at the planned time. At the end of the charging plan, the original settings are restored by a "Restore" command.

[0057] The sequence shown illustrates how external partners can implement dynamic charging behavior with multiple charging and pause phases via defined API commands, without triggering unnecessary switching cycles in the vehicle. The combination of time-slot control and instant charging serves to create a grid-friendly, cost-optimized, and vehicle-integrated charging profile.

[0058] Fig. Figure 4 shows that the multiple operating modes include at least the following states, namely charging in a "Instant Charging" mode (abbreviated as "Imm" in Fig. 4), in which vehicle 202 is currently being charged; charging in a "time slot charging" mode (abbreviated as "TW-in" in Fig. 4) within an active charging time window in which the vehicle 202 is currently being charged; and not charging in a “future time window” mode (abbreviated as “TW fut” in Fig. 4) with a future charging window in which vehicle 202 is not currently being charged. The three different operating modes result in the nine in Fig. The four shown switching options between operating modes. An additional switching cycle is only defined as such if a transition from the "Instant Charging" mode (abbreviated as "Imm") occurs. Fig. 4) or from the active mode “Time Window” (abbreviated as “TW-in” in Fig. 4) into a “future time window” mode (abbreviated as “TW-fut” in Fig. 4) with charging starting in the future.

[0059] The features of the invention described with reference to the embodiments shown may also be present in other embodiments of the invention, unless otherwise stated or is prohibited for technical reasons. Reference symbol list 200 System 201 external control interface 202 vehicles 204 vehicle-specific charging parameters 206 Loading contactor 208 vehicle-side backend 210 Control backend 212 Charging control S1 Procedure step S2 process step S3 process step S4 Procedure step S5 Procedure step S6 Procedure step

Claims

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: - Receiving (S1) a charging mode setting via the external control interface (201), - Providing (S2) vehicle-specific charging parameters (204), - Acquiring (S3) a current state of charge of the vehicle (202) with respect to several operating modes, - Simulating (S4) a state of charge after execution of the received charging mode setting based on the provided vehicle-specific charging parameters (204), - Comparing (S5) the current state of charge and the simulated state of charge of the vehicle (202) to determine whether a transition between the several operating modes occurs that causes a new additional switching cycle of the charging contactor (206), and only in the case of such a transition,- Determine (S6) the received charging mode setting as an additional switching cycle. Method according to claim 1, wherein the vehicle-specific charging parameters (204) include a state of charge, a target state of charge, a connection status to a charging station and / or a configured departure time of the vehicle (202); wherein optionally charging mode settings are ignored if the vehicle (202) is not connected to a charging station and / or the state of charge is at least equal to the target state of charge. Method according to one of the preceding claims, wherein the multiple operating modes comprise at least the following states: a) charging in an “instant charging” mode in which the vehicle (202) is currently being charged, b) charging in a “time window charging” mode within an active charging time window in which the vehicle (202) is currently being charged, and c) not 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. Method according to one of the preceding claims, wherein an additional switching cycle is determined only if there is a transition from the "instant charging" mode or from the active "time window" mode to a "future time window" mode with charging starting in the future; and / or wherein the simulation (S4) of the state of charge comprises anticipating a charging decision of the vehicle (202) after application and / or acceptance of the charging mode setting. A method according to any of the preceding claims, wherein only charging mode settings are counted for which a switching cycle-triggering transition has been identified by the simulation; and / or wherein the method is used to control the limitation of switching cycles caused by external control commands. Method according to one of the preceding claims, wherein the decision on the existence of a switching cycle-triggering transition is documented in a charging event database; and / or wherein each counted switching cycle is assigned a vehicle identifier, and a cumulative count is managed in a vehicle-specific manner. Method according to one of the preceding claims, wherein a notification is sent to a charging planning operator when a predefined switching cycle limit for a vehicle (202) is exceeded; and / or wherein the charging cycle recording is used for billing API usage to an external partner. System (200) for determining additional switching cycles of a charging contactor (206) included in a vehicle (202) comprising: - a vehicle (202) with a charging contactor (206), - a vehicle-side backend (208) for providing vehicle-specific charging parameters (204), - an external control interface, API, (201) for communicating charging mode settings by external partners, - a control backend (210) configured to receive charging mode settings, detect the current state of charge of the vehicle (202), simulate the state of charge after execution of the charging mode setting, and determine, based on the comparison of the current state of charge and the simulated state of charge, whether an additional switching cycle is caused. Computer program product comprising a program code which, when executed on a computer, performs a method according to one of claims 1 to 7, wherein the program code is stored on a non-volatile digital storage medium. Computer-readable medium on which the computer program product according to the preceding claim is stored.

Images