EP4381722A1 - Verfahren zur bestimmung eines geeigneten zeitpunkts zur übermittlung von datenpaketen von einem backend an wenigstens eine erste steuereinrichtung eines kraftwagens - Google Patents

Verfahren zur bestimmung eines geeigneten zeitpunkts zur übermittlung von datenpaketen von einem backend an wenigstens eine erste steuereinrichtung eines kraftwagens

Info

Publication number
EP4381722A1
EP4381722A1 EP23726047.6A EP23726047A EP4381722A1 EP 4381722 A1 EP4381722 A1 EP 4381722A1 EP 23726047 A EP23726047 A EP 23726047A EP 4381722 A1 EP4381722 A1 EP 4381722A1
Authority
EP
European Patent Office
Prior art keywords
backend
triggered
vehicle
data packet
transmission
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
EP23726047.6A
Other languages
English (en)
French (fr)
Other versions
EP4381722B1 (de
EP4381722C0 (de
Inventor
Kerstin Schmid
Manuel Gerster
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
Mercedes Benz Group AG
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
Application filed by Mercedes Benz Group AG filed Critical Mercedes Benz Group AG
Publication of EP4381722A1 publication Critical patent/EP4381722A1/de
Application granted granted Critical
Publication of EP4381722B1 publication Critical patent/EP4381722B1/de
Publication of EP4381722C0 publication Critical patent/EP4381722C0/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1835—Buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1848—Time-out mechanisms

Definitions

  • the invention relates to methods for transmitting data packets from a backend to at least a first control device of a motor vehicle according to the preamble of patent claim 1.
  • such an exchange can be “offboard-triggered,” meaning that the exchange is triggered outside the vehicle.
  • the initial data transmission to implement the corresponding functionalities takes place from the backend to the vehicle.
  • the overall process usually corresponds to a “request/response pattern” in which the backend sends a data packet to the vehicle.
  • An example of a “request” would be a command to lock the vehicle and the vehicle
  • the successful processing of the data packet is then confirmed; an example of a “response” would be a confirmation: “Vehicle locked successfully”.
  • the customer does not initiate these functionalities in/on the vehicle itself, but rather via a remote interface, such as a smartphone app, correspondingly “offboard”.
  • Such an exchange can be “onboard-triggered”, which means that the exchange is triggered within the vehicle.
  • the initial data transmission to implement the corresponding functionalities takes place from the vehicle to the backend.
  • the overall process usually also corresponds to a “request/response pattern”, in which the vehicle sends one data packet to the backend and another
  • An example of a “request” would be a command to update status data such as an ignition change or the locking status, with the backend then confirming to the vehicle that the data packet was successfully processed (response).
  • These functionalities are either initiated by the customer in/on the vehicle, for example when the customer unlocks the vehicle, or initiated by the vehicle itself when, for example, the battery level drops, corresponding to “onboard”.
  • the backend usually does not communicate directly with the control device that processes the data packet in the vehicle, but rather via a so-called telecommunications unit (TCU), which has a mobile radio module.
  • TCU telecommunications unit
  • the protocols used do not guarantee successful transmission or delivery of the data packet, at least not at the application level.
  • messages from the TCU can only be received if it is reachable. According to the current state of the art, it is possible for a data packet to be lost on the communication path, both on the way from the backend towards the control device and in the opposite direction.
  • US 9 179488 B2 already discloses a method for restoring a cellular connection between a vehicle telematics unit and a wireless carrier system.
  • This method includes detecting a loss of cellular connection between a vehicle telematics unit and a wireless carrier system and accessing a technology ordering table (TOT) that orders a plurality of radio access technologies (RATs) according to desirability, which in turn are capable of use with the vehicle telematics unit.
  • TOT technology ordering table
  • RATs radio access technologies
  • the method also attempts to restore the cellular connection, in particular through various procedural steps. From US 2019/0141023 A1 a method for configuring access to a vehicle network from a mobile device is known. In the event of an error occurring, a corresponding signaling sequence is started again.
  • the US 2015/0133108 A1 discloses a method for offboard control of a telematics unit of a vehicle through a backend. Sending a request again is briefly discussed without going into further details.
  • the object of the invention is to provide a method in which data packets that have been transmitted to the vehicle but not delivered are retransmitted to the vehicle at a suitable time, so that the data packets are more likely to be received by the vehicle.
  • the invention relates to a method for determining a suitable time for transmitting data packets from a backend to at least one first control device of a vehicle, in particular a motor vehicle, in particular a passenger car, for controlling at least one functionality of the at least one control device.
  • data packets are transmitted and received between the backend and the at least one control device, with the transmission being triggered offboard and/or onboard. It is also possible to transmit all data packets to different control devices for controlling different functions, with the transmission structure being provided with a prioritization, for example.
  • a timer is triggered, in which confirmation information about the receipt of the transmitted offboard-triggered data packet by the backend is awaited .
  • the confirmation information is received, the control of the functionality is confirmed and if the confirmation information is not received, the data packet is temporarily stored in a buffer of the backend for future transmission.
  • the cached ones Data packets are transmitted again to the first control device during an onboard-triggered transmission of further data packets from the same or another control device.
  • the timer should enable messages that were not delivered to the vehicle or data packets that were not transmitted to the respective control device to be resent/transmitted from the perspective of the backend at a suitable time.
  • the timer detects that a message was most likely not delivered. Retransmission at an appropriate time is made possible via the onboard triggered message and the buffer.
  • the solution for determining a suitable time for re-sending data packets in the case of offboard-triggered functionalities is done with the help of the onboard-triggered functionalities and under the assumption that the communication between backend and vehicle takes place via a request/response pattern and that vehicle can handle receiving the same data packets multiple times.
  • the onboard-triggered functionality triggers a new attempt to transmit the data packets that were not transmitted if the offboard-triggered functionality failed. If there is no response in the case of offboard-triggered functionality for a certain period of time or after the timer has expired, it must be assumed in the backend that the corresponding data packet has not reached the vehicle or the control device. The backend must therefore temporarily store the data packet intended for the vehicle or for a control device.
  • the suitable time or trigger for the re-sending or re-transmission of the data packet is then the successful receipt of data packets that the vehicle or the respective control devices send to the backend as part of an onboard-triggered functionality.
  • the sending of these data packets is triggered by the vehicle or the respective control devices themselves and therefore independently of the offboard-triggered functionality, for example when the customer unlocks the vehicle or changes the ignition and usually takes place in a different context than that of the offboard-triggered functionality. triggered functionality.
  • the receipt of a data packet from the vehicle or the respective control devices justifies the assumption that the vehicle or the control devices can be reached again and therefore data packets sent by the backend will also be received with a very high probability. This means that the probability of one individual transmission without query is lower than that of the method according to the invention, since at least one further transmission is carried out here.
  • a check is carried out to determine whether the retransmitted data packets are necessary. This means that certain functionalities are checked in the buffer to see if they are necessary at the time the onboard-triggered functionality appears. For example, it is no longer necessary to secure a lock after getting into the car, which means that it can be deleted from the buffer again. To ensure security, for example, any functionality that was not performed can be logged and saved for further processing, which means that less storage space and working memory are required.
  • the buffer is deleted after a successful onboard-triggered transmission.
  • the cache can be deleted either as a direct consequence of the onboard-triggered functionality or as a delayed consequence, whereby the specification for deletion is specified by the OEM. In particular, the safety of the vehicle should be given priority.
  • An embodiment of the invention has also proven to be advantageous, in which information about them is transmitted to a data receiver if transmissions of offboard-triggered data packets are not confirmed. This is advantageous due to the security precautions at the application level, since a user of the application receives a warning as soon as the backend receives confirmation information. This can lead to greater security for various functionalities, for example if the vehicle is not locked.
  • a further second timer and / or further timers are triggered, in which the confirmation information about the receipt of the previously buffered data packet of the offboard-triggered
  • the backend waits for the transmission to be sent again, and if it is not received again, a signal is generated to trigger an error message.
  • the error message confirms with a certain probability a possible interruption of an interface between the backend and control device and informs the user or the OEM that a possible physical connection/interfaces or other components is/are defective.
  • This invention is in the field of telematics and describes a method which, from the perspective of a vehicle backend, allows messages that were not delivered to the vehicle to be resent to the vehicle at an appropriate time.
  • FIG. shows a schematic image diagram to illustrate a method according to the invention.
  • identical and functionally identical elements are provided with the same reference numerals.
  • FIG. shows an example of the application of the method according to the invention, in which at least one first control device 14a of a vehicle 16, in particular a motor vehicle, is used to determine a suitable time for transmitting data packets 10 from a backend 12 to the control at least one functionality of the at least one control device 14a.
  • the data packets 10 are transmitted and received between the backend 12 and the at least one control device 14a, with the triggering of the transmission being triggered offboard B1 and/or onboard B2.
  • a timer T is triggered, in which confirmation information 18 about the receipt of the transmitted offboard-triggered B1 data packet 10 by the backend 12 is waited for, with the confirmation information being received 18 the control of the functionality is confirmed and if the confirmation information 18 is not received, and thus if non-confirmation information 28 is transmitted, the data packet 10 is buffered in a buffer 20 of the backend 12 for future transmission.
  • the non-confirmation information 28 from the vehicle 16 to the backend 12 is in particular the expiration of the timer T, which can be passed on to other entities. Eventually they will cached data packets 10 are retransmitted to the at least one control device 14a during an onboard-triggered B2 transmission of further data packets 10b.
  • FIG. uses an example in which a customer/user 22 wants to have a functionality shown as pre-air conditioning of his vehicle 16, which is designed as an electric vehicle, configured via the OEM's smartphone app 26 in such a way that the pre-air conditioning on one The specified afternoon at 2 p.m. is activated in the vehicle 16, which involves an offboard-triggered B1 transmission of data packets 10 for this functionality.
  • a pre-air conditioning command 24 is transmitted to the vehicle 16 via the backend 12.
  • a request data packet 10a is first sent to the backend 12, then this data packet 10, which is designed as a command data packet, is sent from the backend 12 to the vehicle 16 and/or the control device 14a.
  • the data packets 10, 10a differ in that the command data packet or data packet 10 applies between the vehicle 16 and backend 12 and the data packet 10a applies between backend 12 and customer/user 22.
  • the backend 12 sends a corresponding data packet 10 with a pre-air conditioning command 24 for configuring the pre-air conditioning to the vehicle 16, which contains, among other things, the activation time. If the backend 12 does not receive the expected confirmation information 18 or a “response” to the sent data packet 10 within a certain period of time or within the timer T, it can be assumed that the data packet 10 does not reach the vehicle 16 or the control device 14a reached and the pre-air conditioning 24 was not configured according to the customer's wishes.
  • the backend 12 waits according to the present method until the vehicle 16 sends another one Data packet 10b receives which was sent as part of an onboard-triggered B2 functionality, for example when the vehicle 16 connected for charging sends a new charge status to the backend 12.
  • This data packet 10b which is not related to the pre-air conditioning 24, thus triggers a repetition of the buffered data packet 10, which has a very high probability is received by the vehicle 16 or by the control device 14a and thus leads to a configuration of the pre-air conditioning 24 in the vehicle 16 and corresponding confirmation information 18 to the backend 12.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Lock And Its Accessories (AREA)
  • Selective Calling Equipment (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Bestimmung eines geeigneten Zeitpunkts zur Übermittlung von Datenpaketen (10) von einem Backend (12) an wenigstens eine erste Steuereinrichtung (14a) eines Kraftwagens (16) zur Steuerung wenigstens einer Funktionalität der wenigstens einen Steuereinrichtung (14a), bei welchem Datenpakete (10) zwischen dem Backend (12) und der wenigstens einen Steuereinrichtung (14a) übermittelt und empfangen werden, wobei die Übermittlung offboard (B1) und/oder onboard (B2) getriggert wird.

Description

Verfahren zur Bestimmung eines geeigneten Zeitpunkts zur Übermittlung von Datenpaketen von einem Backend an wenigstens eine erste Steuereinrichtung eines Kraftwagens
Die Erfindung betrifft Verfahren zur Übermittlung von Datenpaketen von einem Backend an wenigstens eine erste Steuereinrichtung eines Kraftwagens gemäß dem Oberbegriff von Patentanspruch 1.
Aktuelle Fahrzeuge beziehungsweise Kraftwägen verfügen über zahlreiche vernetzte Steuereinrichtungen beziehungsweise Steuergeräte, welche Daten mit einem Fahrzeug- Backend austauschen, wobei hier zwischen zwei Arten von Funktionalitäten unterschieden werden kann.
Einerseits kann ein solcher Austausch „offboard-getriggert“ sein, das heißt, dass der Austausch außerhalb des Fahrzeugs ausgelöst wird. Der initiale Datenversand zur Realisierung entsprechender Funktionalitäten erfolgt vom Backend aus an das Fahrzeug. Der Gesamtablauf entspricht in der Regel einem (engl.) „Request/Response-Pattern“, bei dem das Backend dem Fahrzeug ein Datenpaket sendet, ein Beispiel für (engl.) „Request“ wäre ein Befehl zur Verriegelung des Fahrzeugs, und das Fahrzeug die erfolgreiche Verarbeitung des Datenpakets anschließend bestätigt, ein Beispiel für (engl.) “Response“ wäre eine Bestätigung: „Fahrzeug erfolgreich verriegelt“. Diese Funktionalitäten initiiert der Kunde nicht im/am Fahrzeug selbst, sondern über eine Remote-Schnittstelle, wie zum Beispiel eine Smartphone-App, entsprechend (engl.) „offboard“.
Andererseits kann ein solcher Austausch „onboard-getriggert“ sein, das heißt, dass der Austausch innerhalb des Fahrzeugs ausgelöst wird. Der initiale Datenversand zur Realisierung entsprechender Funktionalitäten erfolgt vom Fahrzeug aus an das Backend. Der Gesamtablauf entspricht in der Regel ebenfalls einem (engl.) „Request/Response- Pattern“, bei dem das Fahrzeug dem Backend ein Datenpaket sendet, ein weiteres Beispiel für (engl.) „Request“ wäre ein Befehl zur Aktualisierung von Statusdaten wie einen Zündungswechsel oder den Verriegelungsstatus, wobei das Backend dem Fahrzeug die erfolgreiche Verarbeitung des Datenpakets anschließend bestätigt (engl.) „response“. Diese Funktionalitäten werden entweder vom Kunden im/am Fahrzeug initiiert, wenn beispielsweise der Kunde das Fahrzeug entriegelt, oder vom Fahrzeug selbst initiiert, wenn beispielsweise der Batteriestand sinkt, entsprechend (engl.) „onboard“.
Das Backend kommuniziert in der Regel nicht direkt mit der Steuereinrichtung, welche das Datenpaket im Fahrzeug verarbeitet, sondern über eine sogenannte Telekommunikationseinheit (TCU), die über ein Mobilfunkmodul verfügt. Die TCU stellt zwar eine abgesicherte Verbindung zum Backend sicher, aber die eingesetzten Protokolle garantieren keine erfolgreiche Übermittlung beziehungsweise Zustellung des Datenpakets, zumindest nicht auf applikativer Ebene. Zudem können Nachrichten von der TCU nur empfangen werden, wenn diese erreichbar ist. So ist es gemäß heutigem Stand der Technik möglich, dass ein Datenpaket auf dem Kommunikationsweg verloren geht, und zwar sowohl auf dem Weg vom Backend in Richtung Steuereinrichtung als auch in die entgegengesetzte Richtung.
Aufgrund von äußeren Einflüssen besteht die Möglichkeit, dass im Falle von offboard- getriggerten Funktionalitäten Datenpakete dem Fahrzeug nicht zugestellt werden können, wie beispielsweise bei fehlender oder schlechter Mobilfunkverbindung. Dennoch gibt es Datenpakete, die einem Fahrzeug für die erfolgreiche Bereitstellung diverser offboard- getriggerter Kundenfunktionalitäten zwingend zugestellt werden müssen. Abhängig von der Kundenfunktionalität muss die Zustellung der Datenpakete aber nicht zwingend unmittelbar erfolgen.
In der US 9 179488 B2 ist bereits ein Verfahren zum Wiederherstellen einer zellularen Verbindung zwischen einer Fahrzeugtelematikeinheit und einem drahtlosen Trägersystem offenbart. Dieses Verfahren umfasst das Erfassen eines Verlustes der zellularen Verbindung zwischen einer Fahrzeugtelematikeinheit und einem drahtlosen Trägersystem sowie das Zugreifen auf eine Technologiebestellungstabelle (TOT), die eine Vielzahl von Funkzugangstechnologien (RATs) entsprechend der Erwünschtheit ordnet, die wiederum zur Verwendung bei der Fahrzeugtelematikeinheit fähig sind. Ebenso versucht das Verfahren die zellulare Verbindung wiederherzustellen, insbesondere durch verschiedene Verfahrensschritte. Aus der US 2019/0141023 A1 ist ein Verfahren zum Konfigurieren eines Zugangs zu einem Fahrzeugnetzwerk von einer mobilen Vorrichtung bekannt. Im Falle eines auftretenden Fehlers wird hierbei eine entsprechende Signalisierungssequenz erneut gestartet.
Die US 2015/0133108 A1 offenbart ein Verfahren zur Offboard-Steuerung einer Telematikeinheit eines Fahrzeugs durch ein Backend. Ein erneutes Senden einer Anfrage wird kurz angesprochen ohne auf weitere Ausführungen hierzu einzugehen.
Aufgabe der Erfindung ist es, ein Verfahren bereitzustellen, bei welchem an das Fahrzeug übermittelte, aber nicht zugestellte Datenpakete an einem geeigneten Zeitpunkt erneut an das Fahrzeug übermittelt werden, sodass die Datenpakete mit höherer Wahrscheinlichkeit vom Fahrzeug empfangen werden.
Diese Aufgabe wird mittels eines Verfahrens mit den Merkmalen des Patentanspruchs 1 gelöst. Vorteilhafte Ausgestaltungen mit zweckmäßigen Weiterbildungen der Erfindung sind in den übrigen Patentansprüchen angegeben.
Die Erfindung betrifft ein Verfahren zur Bestimmung eines geeigneten Zeitpunkts zur Übermittlung von Datenpaketen von einem Backend an wenigstens eine erste Steuereinrichtung eines Fahrzeugs, insbesondere eines Kraftwagens, insbesondere eines Personenkraftwagens, zur Steuerung wenigstens einer Funktionalität der wenigstens einen Steuereinrichtung. Hierbei werden Datenpakete zwischen dem Backend und der wenigstens einen Steuereinrichtung übermittelt und empfangen, wobei das Auslösen der Übermittlung offboard und/oder onboard getriggert wird. Es ist ebenso möglich, sämtliche Datenpakete an verschiedene Steuereinrichtungen zur Steuerung verschiedener Funktionalität zu übermitteln, wobei die Übermittlungsstruktur beispielsweise mit einer Priorisierung versehen wird.
Um die Aufgabe der Erfindung zu lösen, ist es erfindungsgemäß vorgesehen, dass bei einer offboard-getriggerten Übermittlung wenigstens eines Datenpakets an die erste Steuereinrichtung ein Timer ausgelöst wird, in welchem eine Bestätigungsinformation über das Empfangen des übermittelten offboard-getriggerten Datenpakets durch das Backend abgewartet wird. Hierbei wird bei Empfangen der Bestätigungsinformation die Steuerung der Funktionalität bestätigt und bei einem nicht Empfangen der Bestätigungsinformation das Datenpaket in einem Zwischenspeicher des Backends für eine zukünftige Übermittlung zwischengespeichert. Die zwischengespeicherten Datenpakete werden, bei einer onboard-getriggerten Übermittlung weiterer Datenpakete von selbiger oder einer weiteren Steuereinrichtung, erneut an die erste Steuereinrichtung übermittelt. Insbesondere soll der Timer ermöglichen, dass aus Sicht des Backends nicht an das Fahrzeug zugestellte Nachrichten beziehungsweise nicht an die jeweilige Steuereinrichtung übermittelte Datenpakete zu einem geeigneten Zeitpunkt erneut gesendet/übermittelt werden. Über den Timer wird erkannt, dass eine Nachricht sehr wahrscheinlich nicht zugestellt wurde. Die erneute Übermittlung zu einem geeigneten Zeitpunkt wird über die onboard-getriggerte Nachricht und den Zwischenspeicher ermöglicht.
Die Lösung zum Bestimmen eines geeigneten Zeitpunkts für den erneuten Versand von Datenpaketen im Falle von offboard-getriggerten Funktionalitäten erfolgt mit Zuhilfenahme der onboard-getriggerten Funktionalitäten und unter der Annahme, dass die Kommunikation zwischen Backend und Fahrzeug über ein Request/Response-Pattern erfolgt und das Fahrzeug damit umgehen kann, dieselben Datenpakete mehrmals zu erhalten. In anderen Worten löst die onboard-getriggerte Funktionalität einen erneuten Versuch aus, die nicht übermittelten Datenpakete bei der fehlgeschlagenen offboard- getriggerten Funktionalität zu übermitteln. Bleibt die Response im Falle einer offboard- getriggerten Funktionalität für einen gewissen Zeitraum beziehungsweise nach Ablauf des Timers aus, muss im Backend davon ausgegangen werden, dass das entsprechende Datenpaket das Fahrzeug beziehungsweise die eine Steuereinrichtung nicht erreicht hat. Das Backend muss das für das Fahrzeug beziehungsweise für die eine Steuereinrichtung bestimmte Datenpaket deshalb Zwischenspeichern.
Der geeignete Zeitpunkt beziehungsweise Auslöser für den erneuten Versand beziehungsweise für die erneute Übermittlung des Datenpakets ist dann der erfolgreiche Empfang von Datenpaketen, die das Fahrzeug beziehungsweise die jeweiligen Steuereinrichtungen im Rahmen einer onboard-getriggerten Funktionalität an das Backend versenden. Der Versand dieser Datenpakete wird vom Fahrzeug oder der jeweiligen Steuereinrichtungen selbst und somit unabhängig von der offboard-getriggerten Funktionalität ausgelöst, zum Beispiel, wenn der Kunde das Fahrzeug entriegelt oder einen Zündungswechsel vornimmt und erfolgt in der Regel in einem anderen Kontext als der der offboard-getriggerten Funktionalität. Der Empfang eines Datenpakets des Fahrzeugs beziehungsweise der jeweiligen Steuereinrichtungen rechtfertigt die Annahme, dass das Fahrzeug beziehungsweise die Steuereinrichtungen wieder erreichbar ist/sind und somit auch vom Backend versendete Datenpakete mit einer sehr hohen Wahrscheinlichkeit empfangen werden. Das heißt, dass die Wahrscheinlichkeit zu einer einzelnen Übermittlung ohne Abfrage geringer ist als die des erfindungsgemäßen Verfahrens, da hier wenigstens eine weitere Übermittlung durchgeführt wird.
In einer vorteilhaften Ausgestaltung der Erfindung ist es vorgesehen, dass eine Überprüfung über eine Notwendigkeit der erneut übermittelten Datenpakete durchgeführt wird. Dies bedeutet, dass im Zwischenspeicher gewisse Funktionalitäten auf deren Notwendigkeit zu dem Zeitpunkt, an dem die onboard-getriggerte Funktionalität erscheint, überprüft werden. Beispielsweise ist eine Absicherung eines Schlosses nach einsteigen in das Auto nicht weiter notwendig, wodurch diese wieder aus dem Zwischenspeicher gelöscht werden kann. Zur Absicherung der Sicherheit kann hierbei beispielweise jede nicht erfolgte Funktionalität protokolliert werden und zur weiteren Verarbeitung gespeichert werden, wodurch weniger Speicherplatz als auch Arbeitsspeicher benötigt wird.
In einer weiteren vorteilhaften Ausgestaltung der Erfindung ist es vorgesehen, dass der Zwischenspeicher nach einer erfolgreichen onboard-getriggerten Übermittlung gelöscht wird. Die Löschung des Zwischenspeichers kann hierbei sowohl als direkte Konsequenz der onboard-getriggerten Funktionalität als auch als zeitlich versetzte Konsequenz durchgeführt werden, wobei die Vorgabe zum Löschen vom OEM vorgegeben wird. Insbesondere soll hierbei die Sicherheit des Fahrzeugs priorisiert sein.
Weiterhin vorteilhaft hat sich eine Ausgestaltung der Erfindung erwiesen, in welcher bei nicht bestätigten Übermittlungen von offboard-getriggerten Datenpaketen eine Information darüber an einen Datenempfänger übermittelt wird. Dies ist aufgrund der Sicherheitsvorkehrung auf applikativer Ebene von Vorteil, da hierbei ein Nutzer der Applikation eine Warnung empfängt, sobald das Backend eine Bestätigungsinformation empfängt. So kann dies bei verschiedenen Funktionalitäten zu einer höheren Sicherheit führen, beispielweise bei nicht erfolgtem Zusperren des Fahrzeugs.
Schließlich ist es in einer vorteilhaften Ausgestaltung der Erfindung vorgesehen, dass nach einer bestätigten onboard-getriggerten Übermittlungen von Datenpaketen ein weiterer zweiter Timer und/oder weitere Timer ausgelöst wird/werden, in welchem die Bestätigungsinformation über das Empfangen des zuvor zwischengespeicherten Datenpakets der offboard-getriggerten Übermittlung durch das Backend erneut abgewartet wird, und bei einem erneuten nicht Empfangen ein Signal zum Auslösen einer Fehlermeldung erzeugt wird. Die Fehlermeldung bestätigt zu einer gewissen Wahrscheinlichkeit eine mögliche Unterbrechung einer Schnittstelle zwischen Backend und Steuereinrichtung und weist den Nutzer oder den OEM darauf hin, dass eine mögliche physische Verbindung/Schnittstellen oder weitere Komponenten defekt ist/sind.
Diese Erfindung ist aus dem Gebiet der Telematik und beschreibt ein Verfahren, welches es erlaubt, aus Sicht eines Fahrzeug-Backends nicht an das Fahrzeug zugestellte Nachrichten zu einem geeigneten Zeitpunkt erneut an das Fahrzeug zu senden.
Weitere Vorteile, Merkmale und Einzelheiten der Erfindung ergeben sich aus der nachfolgenden Beschreibung eines bevorzugten Ausführungsbeispiels sowie anhand der Zeichnung. Die vorstehend in der Beschreibung genannten Merkmale und Merkmalskombinationen sowie die nachfolgend in der Figurenbeschreibung genannten und/oder in der einzigen Figur alleine gezeigten Merkmale und Merkmalskombinationen sind nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar, ohne den Rahmen der Erfindung zu verlassen.
Dabei zeigt die einzige Figur (Fig.) ein schematisches Bilddiagramm zur Darstellung eines erfindungsgemäßen Verfahrens. In den Figuren sind gleiche und funktionsgleiche Elemente mit den gleichen Bezugszeichen versehen.
In der einzigen Figur (Fig.) wird ein Beispiel zur Anwendung des Erfindungsgemäßen Verfahrens dargestellt, bei welchem zur Bestimmung eines geeigneten Zeitpunkts zur Übermittlung von Datenpaketen 10 von einem Backend 12 an wenigstens eine erste Steuereinrichtung 14a eines Fahrzeugs 16, insbesondere eines Kraftwagens, zur Steuerung wenigstens einer Funktionalität der wenigstens einen Steuereinrichtung 14a. Es werden die Datenpakete 10 zwischen dem Backend 12 und der wenigstens einen Steuereinrichtung 14a übermittelt und empfangen, wobei das Auslösen der Übermittlung offboard B1 und/oder onboard B2 getriggert wird. Bei einer offboard-getriggerten B1 Übermittlung wenigstens eines Datenpakets 10 an die erste Steuereinrichtung 14a wird ein Timer T ausgelöst, in welchem eine Bestätigungsinformation 18 über das Empfangen des übermittelten offboard-getriggerten B1 Datenpakets 10 durch das Backend 12 abgewartet wird, wobei bei Empfangen der Bestätigungsinformation 18 die Steuerung der Funktionalität bestätigt wird und bei einem nicht Empfangen der Bestätigungsinformation 18, und somit bei einer Übermittlung einer Nichtbestätigungsinformation 28, das Datenpaket 10 in einem Zwischenspeicher 20 des Backends 12 für eine zukünftige Übermittlung zwischengespeichert wird. Die Nichtbestätigungsinformation 28 vom Fahrzeug 16 an das Backend 12 ist insbesondere der Ablauf des Timers T, welche an weitere Entitäten weitergegeben werden kann. Schließlich werden die zwischengespeicherten Datenpakete 10 bei einer onboard-getriggerten B2 Übermittlung weiterer Datenpakete 10b an die wenigstens eine Steuereinrichtung 14a erneut übermittelt.
Die einzige Figur (Fig.) bedient sich hierbei an einem Beispiel, bei welchem ein Kunde/Nutzer 22 eine als Vorklimatisierung dargestellte Funktionalität seines als Elektrofahrzeug ausgebildetes Fahrzeug 16 über die Smartphone-App 26 des OEM so konfiguriert haben will, dass die Vorklimatisierung an einem vorgegebenen Nachmittag um 14 Uhr im Fahrzeug 16 aktiviert wird, wobei es sich über eine offboard-getriggerte B1 Übermittlung von Datenpaketen 10 für diese Funktionalität handelt. Hierbei wird für die Vorklimatisierung ein Vorklimatisierungsbefehl 24 über das Backend 12 an das Fahrzeug 16 übermittelt. Hierbei wird zunächst ein Anfrage-Datenpaket 10a an das Backend 12 gesendet, anschließend dieses als Befehlsdatenpaket ausgebildete Datenpaket 10 vom Backend 12 an das Fahrzeug 16 und/oder der Steuereinrichtung 14a gesendet. In anderen Worten unterscheiden sich die Datenpakete 10, 10a, darin, dass zwischen Fahrzeug 16 und Backend 12 das Befehlsdatenpaket beziehungsweise Datenpaket 10 und zwischen Backend 12 und Kunde/Nutzer 22 das Datenpaket 10a gelten.
Sobald der Kunde/Nutzer 22 eine gewünschte Aktivierungszeit in der Smartphone-App 26 konfiguriert, sendet das Backend 12 ein entsprechendes Datenpaket 10 mit einem Vorklimatisierungsbefehl 24 zur Konfiguration der Vorklimatisierung an das Fahrzeug 16, das unter anderem die Aktivierungszeit enthält. Sollte das Backend 12 die erwartete Bestätigungsinformation 18 beziehungsweise ein (engl.) „response“ auf das versendete Datenpaket 10 innerhalb eines gewissen Zeitraums beziehungsweise innerhalb des Timers T nicht erhalten, ist davon auszugehen, dass das Datenpaket 10 das Fahrzeug 16 beziehungsweise die Steuereinrichtung 14a nicht erreicht hat und die Vorklimatisierung 24 nicht dem Kundenwunsch entsprechend konfiguriert wurde.
Anstatt das Datenpaket 10 in zyklischen Zeitabständen an das Fahrzeug 16 beziehungsweise an die Steuereinrichtung 14a zu senden oder den Kunde/Nutzer 22 die Konfiguration der Aktivierungszeit erneut durchführen zu lassen, wartet das Backend 12 gemäß dem vorliegenden Verfahren ab, bis es vom Fahrzeug 16 ein weiteres Datenpaket 10b erhält, welches im Rahmen einer onboard-getriggerten B2 Funktionalität versendet wurde, zum Beispiel wenn das zum Laden angeschlossene Fahrzeug 16 einen neuen Ladezustand an das Backend 12 sendet. Dieses nicht mit der Vorklimatisierung 24 in Kontext stehende Datenpaket 10b löst somit eine Wiederholung des zwischengespeicherten Datenpakets 10 aus, welches mit sehr hoher Wahrscheinlichkeit vom Fahrzeug 16 beziehungsweise von der Steuereinrichtung 14a empfangen wird und somit zu einer Konfiguration der Vorklimatisierung 24 im Fahrzeug 16 und einer entsprechenden Bestätigungsinformation 18 an das Backend 12 führt.

Claims

Patentansprüche Verfahren zur Bestimmung eines geeigneten Zeitpunkts zur Übermittlung von Datenpaketen (10) von einem Backend (12) an wenigstens eine erste Steuereinrichtung (14a) eines Kraftwagens (16) zur Steuerung wenigstens einer Funktionalität der wenigstens einen Steuereinrichtung (14a), bei welchem Datenpakete (10) zwischen dem Backend (12) und der wenigstens einen Steuereinrichtung (14a) übermittelt und empfangen werden, wobei die Übermittlung offboard (B1) und/oder onboard (B2) getriggert wird, dadurch gekennzeichnet, dass bei einer offboard-getriggerten (B1) Übermittlung wenigstens eines Datenpakets (10) an die erste Steuereinrichtung (14a) ein Timer (T) ausgelöst wird, in welchem eine Bestätigungsinformation (18) über das Empfangen des wenigstens einen übermittelten und offboard-getriggerten (B1) Datenpakets (10) durch das Backend (12) abgewartet wird, wobei bei einem Empfangen der Bestätigungsinformation (18) die Steuerung der Funktionalität bestätigt wird und bei einem nicht Empfangen der Bestätigungsinformation (18) das wenigstens eine Datenpaket (10) in einem Zwischenspeicher (20) des Backends (12) für eine zukünftige Übermittlung zwischengespeichert wird, und das wenigstens eine zwischengespeicherte Datenpaket (10), bei einer onboard-getriggerten (B2) Übermittlung weiterer Datenpakete (10b) erneut an die Steuereinrichtung (14a) übermittelt wird. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass eine Überprüfung über eine Notwendigkeit des wenigstens einen erneut übermitteltes Datenpakets (10) durchgeführt wird. Verfahren nach einem der vorgehenden Ansprüche 1 und 2, dadurch gekennzeichnet, dass der Zwischenspeicher (20) nach einer erfolgreichen onboard-getriggerten (B2) Übermittlung von Datenpakete (10b) gelöscht wird. Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, dass bei nicht bestätigten offboard-getriggerten (B1) Übermittlungen von Datenpakete (10) eine Nichtbestätigungsinformation (28) an einen Datenempfänger (30) übermittelt wird. Verfahren nach einem der vorgehenden Ansprüche 2 bis 4, dadurch gekennzeichnet, dass nach einer bestätigten onboard-getriggerten (B2) Übermittlungen von Datenpakete (10b) ein weiterer zweiter Timer ausgelöst wird, in welchem die Bestätigungsinformation (18) über das Empfangen des zuvor zwischengespeicherten Datenpakets (10) der offboard-getriggerten (B1) Übermittlung durch das Backend (12) erneut abgewartet wird, und bei einem erneuten nicht Empfangen ein Signal zum Auslösen einer Fehlermeldung erzeugt wird.
EP23726047.6A 2022-05-24 2023-05-10 Verfahren zur bestimmung eines geeigneten zeitpunkts zur übermittlung von datenpaketen von einem backend an wenigstens eine erste steuereinrichtung eines kraftwagens Active EP4381722B1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022001837.3A DE102022001837B4 (de) 2022-05-24 2022-05-24 Verfahren zur Bestimmung eines geeigneten Zeitpunkts zur Übermittlung von Datenpaketen von einem Backend an wenigstens eine erste Steuereinrichtung eines Kraftwagens
PCT/EP2023/062403 WO2023227371A1 (de) 2022-05-24 2023-05-10 Verfahren zur bestimmung eines geeigneten zeitpunkts zur übermittlung von datenpaketen von einem backend an wenigstens eine erste steuereinrichtung eines kraftwagens

Publications (3)

Publication Number Publication Date
EP4381722A1 true EP4381722A1 (de) 2024-06-12
EP4381722B1 EP4381722B1 (de) 2025-02-26
EP4381722C0 EP4381722C0 (de) 2025-02-26

Family

ID=82402910

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23726047.6A Active EP4381722B1 (de) 2022-05-24 2023-05-10 Verfahren zur bestimmung eines geeigneten zeitpunkts zur übermittlung von datenpaketen von einem backend an wenigstens eine erste steuereinrichtung eines kraftwagens

Country Status (7)

Country Link
US (1) US20250330522A1 (de)
EP (1) EP4381722B1 (de)
JP (1) JP7808211B2 (de)
KR (1) KR20240155310A (de)
CN (1) CN119072916A (de)
DE (1) DE102022001837B4 (de)
WO (1) WO2023227371A1 (de)

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5011686B2 (ja) * 2005-09-02 2012-08-29 トヨタ自動車株式会社 遠隔操作システム
US9420405B2 (en) 2013-11-13 2016-08-16 General Motors Llc Remotely controlling a vehicle telematics unit
US9179488B2 (en) 2014-01-24 2015-11-03 General Motors Llc Vehicle telematics connection retry
JP6915996B2 (ja) * 2017-02-03 2021-08-11 トヨタ自動車株式会社 リモート空調始動システム、サーバ
US10798079B2 (en) 2017-11-07 2020-10-06 Ford Global Technologies, Llc Vehicle with mobile to vehicle automated network provisioning
JP2020167550A (ja) * 2019-03-29 2020-10-08 本田技研工業株式会社 通信装置、通信方法及びプログラム
CN112019579A (zh) 2019-05-30 2020-12-01 比亚迪股份有限公司 车辆网关控制系统、方法及车辆
EP3968601B1 (de) 2020-09-11 2024-05-08 Volkswagen Ag Synchronisation einer kommunikation zwischen einem fahrzeug und einer backend-vorrichtung durch verwendung einer hash-meldung

Also Published As

Publication number Publication date
EP4381722B1 (de) 2025-02-26
WO2023227371A1 (de) 2023-11-30
EP4381722C0 (de) 2025-02-26
US20250330522A1 (en) 2025-10-23
CN119072916A (zh) 2024-12-03
JP2025517925A (ja) 2025-06-12
DE102022001837A1 (de) 2022-08-04
DE102022001837B4 (de) 2023-06-01
JP7808211B2 (ja) 2026-01-28
KR20240155310A (ko) 2024-10-28

Similar Documents

Publication Publication Date Title
DE102012223124B4 (de) Fahrzeugkommunikationssteuervorrichtung
EP1518383B1 (de) Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug
WO2004019209A1 (de) Vorrichtung zum zugriff auf ein fahrzeugssteuersystem über eine drahtlose verbindung
DE102007030608A1 (de) Fahrzeug-Kommunikationssystem
DE102017206381A1 (de) Verfahren und Vorrichtungen betreffend insbesondere ein Kraftfahrzeugzugangs-und/oder-Start-System
EP0838569A2 (de) Elektronischer Fahrzeugschlüssel
DE102017109099A1 (de) Bereitstellen von modul-updates für ein fahrzeugsystem
DE102004039964A1 (de) Aktualisierungsverfahren für das drahtlose System eines Fahrzeug-Sicherheitssystems
EP1178455A2 (de) Verfahren und System zur Übertragung von Daten
DE10326287A1 (de) Fahrzeug-Kommunikationssystem, welches eine anormale Steuereinheit initialisiert
WO2013092812A1 (de) Teilnehmerstation eines bussystems und verfahren zur übertragung von nachrichten zwischen teilnehmerstationen eines bussystems
DE102012023648B4 (de) Verfahren und System zum Aktualisieren von einem Steuergerät eines Kraftwagens
EP0989701A2 (de) Datenbus
DE112019004998T5 (de) Zentralvorrichtung, Datenkommunikationssystem und Datenkommunikationsprogramm
EP4381722B1 (de) Verfahren zur bestimmung eines geeigneten zeitpunkts zur übermittlung von datenpaketen von einem backend an wenigstens eine erste steuereinrichtung eines kraftwagens
DE102013004917A1 (de) Verfahren und System zur Fernauslesung von Daten eines Fahrzeugs zur Unterstützung der Wartung und/oder der Reparatur des Fahrzeugs, Telekommunikationsendgerät, Computerprogramm und Computerprogrammprodukt
DE102015016928A1 (de) Verfahren zum Betrieb eines Fahrzeugs
EP1516499B1 (de) Verfahren und vorrichtung zum aufbau einer kommunikationsverbindung zwischen einer zentrale und einem endgerät
EP1245453B1 (de) Steuerungssystem und Verfahren zur Steuerung von Kraftfahrzeugkomponenten
DE10304243B4 (de) Verfahren und Vorrichtung zur Steuerung einer elektrischen Einrichtung eines Fahrzeugs
EP1633115A1 (de) Vorrichtung und Verfahren zum Betreiben eines mobilen Kommunikationsgerätes
DE102022001845A1 (de) Verfahren zur Fehlerhandhabung bei einem lnformationsaustausch zwischen einer Steuereinrichtung und einem Backend-Service eines Fahrzeugs
DE102020212452B3 (de) Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft
DE102024206327B3 (de) System und Verfahren zum Einbinden endnutzerspezifischer Zusatzausstattung in eine Bordinfrastruktur eines Kraftfahrzeugs sowie Kraftfahrzeug
EP4544795B1 (de) Erzeugen eines indikators für das angeben einer güte einer datenübertragung

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240304

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
INTG Intention to grant announced

Effective date: 20241125

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 502023000626

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

U01 Request for unitary effect filed

Effective date: 20250319

U07 Unitary effect registered

Designated state(s): AT BE BG DE DK EE FI FR IT LT LU LV MT NL PT RO SE SI

Effective date: 20250324

U20 Renewal fee for the european patent with unitary effect paid

Year of fee payment: 3

Effective date: 20250526

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250526

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250226

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250226

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250526

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250626

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250226

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250527

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250226

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250226

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250226

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20250226

26N No opposition filed

Effective date: 20251127

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20250510