DE102022107169A1 - METHOD, SYSTEM AND COMPUTER PROGRAM FOR TRANSMITTING INFORMATION - Google Patents

Abstract

Examples relate to a method (20) for transmitting information (I) from a vehicle (F) to a backend (B), in particular in connection with an emergency situation. The method (20) comprises the steps: - determining (21) information (I) to be transmitted and then: - varying (22), depending on the information (I) to be transmitted: - a number (N) of from the vehicle ( F) messages to be sent (call); - a time offset Δt between at least two messages (call); or a pattern of at least three messages (call), whereby at least two of the messages (call) differ from the information (I) to be transmitted and have the same content; - Evaluating (23) the number (N), the time offset Δt between two messages (call), and / or a pattern of at least three messages (call) in the backend (B); and - conclusion (24) about the information (I) to be transmitted in the backend (B) depending on the result of the evaluation.

Description

Technical area

Embodiments relate to a method for transmitting information from a vehicle to a backend, in particular in connection with an emergency situation. For example, in connection with eCall (emergency call) messages, it is intended to transmit further information (additional information) in addition to the actual content of the message.

background

In modern motor vehicles, numerous emergency systems (often associated with safety functions) are being used in increasing numbers. One such is the emergency call function (eCall). When an accident is detected, a message with information is automatically sent to an emergency control center so that help can arrive at the scene of the accident as quickly as possible. This functionality, which is known per se, is used in connection with various dangers and incidents.

The eCall messages are characterized by special prioritized treatment within telematics, mobile communications and IT and therefore differ from other formats. This must be the case due to, among other things, legal regulations and other legal reasons. An eCall message has a very small and hard-limited size. In particular, the size and structure cannot be easily changed.

For technical reasons, no further content can be added to an eCall message (e.g. otherwise the size of the message would exceed the intended format). This is also due to the special handling in the IT infrastructure, which is designed for particularly fast and secure transmission of eCall messages. Furthermore, it may be necessary in the future to meet special requirements regarding product monitoring and updates, particularly with regard to automated driving. It may be necessary to use a data transmission channel that can transmit the required (inherently very small) information sufficiently securely and in real time. Both standard and previously planned technologies can sometimes transmit large amounts of data, but sometimes do not meet the requirements regarding security or transmission speed to the desired extent. A change or a short-term establishment of a different or parallel standard would be very cost-intensive.

Summary

It is an object of the present disclosure to provide improved concepts for transmitting information, e.g. whether a vehicle was driven automatically before and/or during an accident, without expanding the content of an eCall message and/or without changing it the IT infrastructure.

According to other concepts, no status regarding automated driving or additional data can be transmitted using the common eCall standard. This means that vehicles that have a problem (e.g. vehicles that have been involved in an accident or that are conspicuous or problematic in connection with automated driving, especially from other manufacturers) cannot be identified as such. It also remains unclear whether the eCall message was triggered during automated driving or in connection with automated driving or not. It is desirable to immediately detect the occurrence of a problem related to automated driving.

The problem is solved according to the subject matter of each of the independent claims. Further advantageous embodiments are described in the dependent claims, the following description and in connection with the figures.

Accordingly, a method for transmitting information from a vehicle to a backend, in particular in connection with an emergency situation, is proposed. The method includes determining information to be transmitted and then varying, depending on the information to be transmitted: - a number of messages to be sent by the vehicle; and/or - a time offset Δt between at least two, in particular a subnumber, of the messages; and/or - a pattern of at least three messages. At least two of the messages (calls) differ from the information (I) to be transmitted and in particular have the same content. Furthermore, the number, the time offset Δt between two or more messages, and/or a pattern of at least three messages are evaluated in the backend, as well as conclusions about the information to be transmitted in the backend depending on the result of the evaluation.

In particular, this can result in the advantage that the method can be designed to be forward-compatible and/or backward-compatible (for example with regard to ever new generations of vehicles). In particular, with a large and growing number of vehicles (the further information to be transferred, e.g. is only required or can be carried out for new vehicles), no change to the standard and/or the vehicles that have already been delivered (e.g. to end customers) is required. Such an advantage is particularly significant for motor vehicles or for a fleet of motor vehicles that includes both “old” and “new” vehicles. For example, the procedure can only be applied to a part of the (e.g. new) vehicles, without there being a need for changes to the proportion of vehicles that have already been delivered and/or without the (possibly common) recipient having to make a fundamental change or set up one new receiver infrastructure must arise. This is particularly advantageous because by changing part of the (e.g. large, global system) there is almost no risk that the messages will not arrive due to a change.

The message is preferably a message containing emergency information from a vehicle. The additional information is preferably information relating to the use of a vehicle system, in particular at least partially automated driving, which corresponds to the emergency of the vehicle, in particular in a temporal and/or causal connection to an emergency. The additional information is understood in particular as that which is not part of the message and/or arises beyond determining the content of the message, in particular comes from another device in the vehicle. For example, information about the status of automated driving is typically information that does not count as part of an emergency message and comes from another device (only available in new vehicles). For the purposes of this document, an emergency is understood to mean, in particular, an accident.

The additional information (which can also be referred to as "further information to be transmitted") can in particular (also) identify various technical parameters of one or more devices of the vehicle (e.g. before, during or after an accident). This can result in a decisive advantage, that (at the latest as a result) both pieces of information can be transmitted to the recipient (in a very fast way specified for the emergency messages). Particularly preferred is the adjustment of a time and / or the time stamp of sending a message, depending on additional information that a Use of one or more functions of the vehicle before and/or during the emergency.

In particular, the additional information can relate to at least partially automated driving, in particular with an automation level of 2, 3 (e.g. according to BaST or a comparable standard). This has the advantage that both the general emergency information and further technical information to be transmitted are made available (in effect immediately and at the same time).

For example, a repeated occurrence of an undesirable and/or specific effect in connection with the use of a certain vehicle functionality and/or a cause of (possibly recurring) emergencies in connection with the use of certain functionalities can be detected (very quickly and effectively). For example, the content of the emergency message (the typical or standard useful content) characterizing the emergency and the (further) information to be transmitted, in particular with regard to the occurrence of certain connections between the two pieces of information, in particular connections that indicate a technical cause of the emergency, can be evaluated become. Appropriate measures can then be taken (e.g. in relation to the vehicle or other vehicles of the same type). In addition, the process can be used to meet new and/or upcoming legal requirements and to improve so-called product monitoring or fleet management.

For example, the message is a standardized message with a fixed structure and size, so that the further information to be transmitted cannot simply be inserted into the message as content. It is therefore suggested that the message be sent twice or multiple times, depending on the type of additional information. In this way, when the recipient receives the message once, they can only draw conclusions about the actual content of the message or (depending on the variant of the method), for example, about a first piece of information to be transmitted. However, if the same message is received twice (or the message with the same payload or payload), it can be concluded that there is a second piece of information to be transmitted. If the message is received three times (e.g. the same message), a corresponding third piece of information can be inferred. The information to be transmitted can therefore be transmitted using the messages without changing the content of the messages, the transmission standard and almost all of the corresponding infrastructure. Rather, a predetermined assignment process (e.g. coding process) (e.g. known for the vehicles and in the backend) can be used. With this, the number of (e.g. standard and/or have the same content) assigns different meanings to messages. The conclusion about the meaning can be made in the backend according to an evaluation process (which can be designed to correspond to the assignment process used on the vehicle).

In other words, it can advantageously be made possible to use an existing and standardized (very extensive) infrastructure, e.g. Emergency Call (eCall), to transmit further information (which was not previously part of eCall, for example) securely and in real time. In particular, the method or system can be implemented without interrupting the ongoing operation of the emergency call infrastructure for the (very numerous) vehicle fleet (existing fleet) or risking a (very undesirable) interruption. An extension that can be carried out in this way is of great importance in industrial practice.

It should be noted that the terms “encoding” and “decoding” or terms derived from these are used for an explanation below, but in particular no encoding or decoding of the message as such takes place or has to take place. Rather, encoding or decoding is used in relation to circumstances (e.g. number of messages, patterns, etc.) that are beyond the messages. In particular, the message itself does not need to be changed at all.

According to one aspect of the method, it is provided that - varying the number of messages, the time offset Δt and / or the pattern of at least three messages in the vehicle takes place in accordance with a coding rule stored in the vehicle or transmitted to the vehicle from the backend; and/or - the evaluation of the number, the time offset Δt between two or more messages, and/or a pattern of at least three messages is carried out in the backend using a decoding rule that corresponds to the coding rule in the vehicle.

Due to the various options for sending two or more messages in relation to each other (e.g. two messages at a short distance from each other and a third at a longer distance from each other), several different pieces of information can be transmitted. For example, the process can also be used to transmit more complex information without having to insert it into the respective messages yourself.

According to one aspect of the method it is provided that - the information to be transmitted is not added to the message or is not transmitted with the message or is not encoded in the message; and/or - no change in the size and/or format of the message; and/or - no change in the content, in particular payloads (P) of a message; and/or - there is no delay in the receipt of the useful content of the message, which is determined by the information to be transmitted.

As already mentioned, it is possible to transmit additional information without having to change the message itself (e.g. in its structural structure or size). The method is therefore particularly suitable for tasks such as those that arise when operating a large fleet of vehicles in which it is not possible to adapt the message, e.g. due to standardization or risk of change.

According to one aspect of the method it is provided that - the message is an emergency message, in particular regarding an accident of the vehicle; and/or - the information to be transmitted identifies a status of one or more functionalities for at least partially automated driving of the vehicle, in particular regarding a time interval before and/or during the occurrence of the emergency situation of the vehicle.

In this way, for example, the information content when sending emergency messages (e.g. eCall) can be expanded. The additional information to be transmitted advantageously matches the content of the type of message originally transmitted.

According to one aspect of the method, it is provided that a conclusion is drawn from the at least one message and the transmitted information: - whether and/or in what temporal and/or causal connection there was with the functionality for at least partially automated driving of the vehicle; and/or - there is an increased risk of an accident in one or more other vehicles.

According to one aspect of the method, it is provided that, depending on several messages and the respective information to be transmitted, a statistical evaluation is determined regarding a specific vehicle type, specific accident type and/or consequences of the accident of the vehicle, and: are taken into account when operating the current vehicle fleet; and/or be taken into account when developing or updating new vehicles.

According to one aspect of the method, it is intended to determine that a message coming from a vehicle indicates a changed number to be sent by a respective vehicle messages and/or a time offset between at least two messages was (was) used, and/or whether and which the allocation rule is used to change a number of messages sent by the (respective) vehicle; and/or a time offset between at least two messages was used. In a simplified case, this can be concluded based on at least almost identical messages from a vehicle. For different vehicles, in particular vehicles with different equipment, initial registration periods, etc., different assignment rules (e.g. known in the backend) can be used.

This can, for example, depend on the first registration date (known both in the vehicle and in the backend), model, equipment variant, a vehicle identification, in particular a VIN (= Vehicle Identification Number) or a predetermined assignment of such data to the use, non-use or a specific use of the procedure. For example, the one or more vehicles and the backend have a (e.g. respective, agreed) list or regulations. This can be used when evaluating the message. The allocation rule can be different for different vehicles. This can further increase discretion and information protection. In particular, it can be determined according to which assignment rule the time and/or time stamp was adjusted. This makes it possible for the messages from both (e.g. comparatively old) vehicles and (e.g. new) vehicles or vehicles that use different allocation rules (simply referred to as coding rules) to adjust a time and/or timestamp. This allows forward compatibility and/or backward compatibility to be enabled or further expanded.

For example, it can be determined in the backend whether the message is received by a vehicle that uses an assignment rule, in particular a specific one, to adjust a time and/or timestamp of sending a message; and then a conclusion can be drawn about the required reassignment rule (decoding rule) and further about the additional information

When applying the method to several vehicles, e.g. a vehicle fleet, an evaluation of the status of individual vehicles in the fleet or the fleet (e.g. in the form of statistics) can be carried out. For example, the additionally transmitted information can provide information as to whether more accidents occur when driving assistants are active (e.g. functions of highly automated driving HAF). The results can be used for the further development of such functions, e.g. for updates or new vehicle developments.

Examples relate to a computer program that includes program code to carry out a disclosed method when the computer program is executed on a processor, a computer, or programmable hardware. Such a computer program can advantageously be provided and executed in a vehicle with eCall functionality or in a system for receiving eCall messages.

Brief description of the characters

• 1 ein schematisches Beispiel eines Systems zum Übertragen von Informationen;
• 2 ein Flussdiagramm eines vorgeschlagenen Verfahrens zum Übermitteln einer Information
• 3 ein schematisches Beispiel eines Sendepfades zum Übermitteln, insbesondere Codieren einer Information; und
• 4 ein schematisches Beispiel eines Empfangspfades zum Decodieren einer eCall Nachricht.

Exemplary embodiments are explained in more detail below with reference to the accompanying figures. Show it:

• 1 a schematic example of a system for transmitting information;
• 2 a flowchart of a proposed method for transmitting information
• 3 a schematic example of a transmission path for transmitting, in particular encoding, information; and
• 4 a schematic example of a reception path for decoding an eCall message.

Description

Various embodiments will now be described in more detail with reference to the accompanying drawings, in which some embodiments are shown. In the figures, the thickness dimensions of lines, layers and/or regions may be exaggerated for clarity. In the following description of the attached figures, which only show a few exemplary embodiments, the same reference numbers can designate the same or comparable components.

An element that is said to be “connected” or “coupled” to another element, that may be directly connected or coupled to the other element, or that there may be intermediate elements. Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meanings as would be assigned to them by one of ordinary skill in the art to which the embodiments pertain.

1 shows a schematic example of a system 10 for transmitting information. It is envisaged that a message call can be sent from a vehicle F to a backend B. In addition to the original content of the call message, additional information I should also be transmitted without increasing the content of the call message (in other words, the same data size can be retained). This can be enabled by a provided coding scheme that involves sending the same message repeatedly. For example, by sending the same message twice, it can advantageously be indicated that a certain status in the vehicle F was active when the message was sent.

Vehicles F1, F2 and F3 are also shown schematically. These can represent a fleet of vehicles. By transmitting the further information I from all of these vehicles F1, F2, F3, for example in the event of an event (e.g. accident), fleet monitoring of a vehicle fleet can be carried out in the backend B. For example, fleet monitoring may include checking whether or not a highly automated driving (HAF) function was activated before and/or while sending an eCall from the respective vehicle.

In the proposed manner of sending the same message multiple times, additional information or further information can advantageously be transmitted in addition to the original message content, without the format, size, and content of the message having to be increased. This means that the content and usability of the call (eCall) message (e.g. from any standardized reception) can still be used.

Some of the vehicles F1, F2, F3, ... may be vehicles that are already in the field (i.e. with users). Your emergency messages can still be evaluated without changing (a complex, worldwide) overall system. Some of the vehicles F1, F2, F3, ... may be vehicles that are designed with new functionalities, in particular with automated driving (e.g. levels 2, 3, 4, 5 according to BaST). When sending your emergency messages eCall, new additional information to be transmitted (e.g. about various status information, parameters, etc.) can always be added, in particular to ever newer functionalities and/or according to ever newer legal or country-specific requirements (e.g. also step by step). A step-by-step expansion can also be possible, in particular without complex changes and/or without interrupting the operation of the system.

Further exemplary details and examples that can be combined with all features regarding the sending of two or more identical messages for encoding additional information are also given in the following figures.

2 shows a flowchart of a proposed method 20 for encoding information. The method 20 includes determining 21 information I to be transmitted and then varying 22, depending on the information to be transmitted: - a number of messages to be sent by the vehicle; and/or - a time offset Δt between at least two, in particular a subnumber, of the messages; and/or - a pattern of at least three messages. At least two of the messages (call) differ from the information to be transmitted (I) and in particular have the same content (eg identical eCall messages). Furthermore, an evaluation 23 of the number, the time offset Δt between two or more messages, and / or a pattern of at least three messages takes place in the backend B, as well as a conclusion 24 about the information to be transmitted in the backend depending on the result of the evaluation 23.

The proposed method can advantageously be applied to any type of message, for example messages according to a certain standard. A specific example regarding the use of messages from the eCall standard is described below.

If it is recognized that the vehicle F was driven automatically before or during an emergency event (e.g. accident), then instead of one, two or more eCall messages are sent, for example. In other words, the vehicle reports the same accident twice instead of once. A time interval between the two messages can be small, e.g. less than 5 seconds (or less than 2 seconds), in order to better ensure the assignment of the messages.

Backend B checks whether one or two messages for the same event were received. For example, a conclusion is made as to whether a HAF (highly automated driving) function was active or not. Advantageously, the limits of the previous eCall format do not have to be left behind and at least one additional bit of information on the HAF status and/or additional useful information can still be transmitted securely and in real time.

According to one example, a coder mode (e.g. a few lines of code) can be installed in front of the module that generates the eCall messages, which, depending on the HAF status, consists of a real trigger (e.g. event of an accident) at least two consecutive triggers (e.g. within a limited time interval). This means that for a real signal (e.g. actual eCall message) a second one (a duplicate or “echo”, so to speak) is also generated and this depends on what the HAF status was. Instead of one eCall message, two or more messages (e.g. with Δt of 1-16 seconds) are triggered. These can be assigned the same as before or differently (see further suggestions below). In the simplest case, the two messages can be eCall messages with the same content (simply a time-delayed duplication). On the receiver side, these can be assigned as belonging to one another using a VIN (vehicle identification number) and/or the same or similar GPS position.

Additional information to be transmitted can be encoded in: - a number N of eCall messages; and/or - the time offset Δt between two or more messages; and/or - a pattern (e.g. a specific sequence, e.g. similar to Morse code) of entire eCall messages. The Δt can be an absolute or relative time offset between the eCalls (see also 3 , there ΔT2). This can refer to the time stamp of the eCall or to the time it was sent or received.

Depending on how many messages arrive in a row and/or at what time interval they arrive at the receiving end, the appropriate meaning can be assigned on the receiving end using a simple decoder (e.g. logically corresponding decoding rule).

The at least two of the eCall messages can be transmitted within a predetermined, limited period of time (e.g. limited to 1, 2, 3, or 5 minutes). This allows the recipient to clearly recognize that there were not multiple emergencies (e.g. accidents) or that the sequence of eCall messages itself has meaning. This means that if their reception and/or timestamp are not further apart than the predefined time period, they should be counted together. As a result, in addition to the actual useful content of the eCall (which can remain unchanged if necessary), a HAF status and, if necessary, further desired information XY can be encoded (telegraphed, so to speak).

For example, even more information than just the HAF status can be encoded. For example, with a third eCall message in a row, the meaning can be assigned that the driver has overruled or taken over (e.g. partially taken over or not taken over) automated driving (e.g. shortly before the emergency event). Alternatively or additionally, the degree of automation actually active at the time of the accident, e.g. individually for longitudinal and lateral guidance (which may differ from the maximum) and/or further useful desired information XY can be coded.

Through a combination of number, time offset Δt and/or pattern of eCall messages, in addition to the content of eCalls, for example more than 4, 8, 16, 32, 64, ... bits can be transmitted within a few seconds (even without anything to change the format or content of individual eCall messages, the infrastructure or anything else).

Advantageously, the proposed method can be introduced at very short notice. Further advantages can include: avoiding high costs, postponements and some risks; Complex, already standardized and unchangeable scopes of the corresponding telematics, mobile communications and IT do not need to be changed; The procedure can be implemented by simply changing the assignment of the eCall messages; Sending multiple eCall messages can be triggered very easily (e.g. manipulative doubling of the trigger); Additional information can be transmitted to the recipient just as quickly and securely as Emergency Call requires; Evaluation of the content of the eCall (cry for help) together with HAF status possible; The process can be displayed in real time.

Further details and aspects are mentioned in connection with the exemplary embodiments described above or below. This in 2 The embodiment shown may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or to one or more of the above (e.g 1 ) or below (e.g 3-4 ) described embodiments are mentioned.

3 shows a schematic example of a transmission path (eg assigned to a vehicle F or formed in the vehicle F) for encoding an eCall message to be sent. A recognition module 31 is designed to recognize events, such as an accident. A coder 32 is designed to specify to a transmission module 34 according to a coding rule 33 how at least two eCall messages should be sent one after the other in a row. Through the coding rule 33, further information I can be transmitted to the backend with the eCall messages without This additional information I (e.g. HAF status, driving action, requested information XY) is itself inserted as content into one of the eCall messages. From the perspective of the proposed method, the backend is a receiving side that can be reached using mobile communications and IT infrastructure (e.g. receiving path also in 4 shown).

A schematic timeline is shown, according to which two eCall messages are sent in accordance with coding rule 33. For example, an accident occurs at a time t _event and a number N of eCall messages are then sent (two eCall messages shown here). The first eCall message can be sent, for example, after a period of time ΔT1 after the accident occurred and the second eCall message after a further period of time ΔT2. The information I can be transmitted by sending two eCall messages instead of one. Alternatively or additionally, the respective time delays ΔT1 and ΔT2 can also be used in order to be able to encode (e.g. further) information I.

By varying the time delays ΔT1 and ΔT2, for example, different information I (e.g. several at once) can be transmitted to the backend B by sending two eCall messages. The sending module 34 may send the two messages according to a coded sequence of triggers (e.g., as if there were multiple emergencies from the same vehicle).

Further details and aspects are mentioned in connection with the exemplary embodiments described above or below. This in 3 The embodiment shown may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or to one or more of the above (e.g 1-2 ) or below (e.g 4 ) described embodiments are mentioned.

4 shows a schematic example of a reception path (e.g. assigned to a backend B) for decoding an eCall message. One or more messages (eg sent by vehicle F) are received via a suitable reception module 41 and then evaluated (eg with regard to the original content of the eCall message such as VIN (vehicle identification number) or GPS position.

A decoder 42 is designed to recognize when several, at least two, eCall messages that belong together (e.g. received promptly, e.g. the same content) are received. In this case, the coding rule 33 can be used to decode further information I from the two received messages. For example, the additional information can be determined based on the time delays ΔT2 between receiving the first and second eCall messages. A first time period of the time delays ΔT2 can, for example, mean first information and a second time period mean second information.

Further details and aspects are mentioned in connection with the exemplary embodiments described above or below. This in 4 The embodiment shown may include one or more optional additional features corresponding to one or more aspects related to the proposed concept or to one or more of the above (e.g 1-3 ) or the exemplary embodiments described below are mentioned.

A further aspect of the invention relates to a vehicle comprising a module for executing the method (on the vehicle side), in particular together with a backend.

Another aspect relates to a backend for executing the method (the receiving method), in particular with one or more (e.g. a large number of) vehicles. The backend can be or comprise an at least partially centralized or at least partially distributed computer structure. Alternatively or additionally, backend may include or be an emergency control center (e.g. at least partially automated and/or at least partially operated by dispatchers).

Another aspect relates to a system consisting of a large number (e.g. a fleet) of vehicles (vehicles), in particular the first vehicles that do not have or transmit any additional information in connection with the emergency and the second vehicles that have or transmit additional information, as well as at least a backend for receiving the information, in particular from both the first vehicles and the second vehicles. The system can have any combination of the features described in this document (e.g. vehicle features, coding modules, backend, decoding module, etc.).

Further examples relate in particular (each) to a method, system and computer program for field monitoring for a HAF fleet. In particular, the proposed use of the existing eCall standard can provide further information regarding the status of highly automated driving (HAF). Vehicles can be transmitted without having to change the eCall message as such.

According to one aspect of the invention, a first computer program, in particular to be understood as a computer program product comprising a first computer program, is proposed, wherein the computer program is designed to carry out the method described in this document when it is executed on at least one computing unit. In particular, the first computer program includes the coder module and/or decoder module.

According to one aspect of the invention, a second computer program, in particular to be understood as a computer program product comprising a second computer program, is proposed, wherein the second computer program during its execution (e.g. as part of a retrofit or update, in particular already after delivery of the vehicle to the user). Change at least one computing component of one or more vehicles, in which the vehicle is set up to execute the first computer program. In other words, the second computer program can be set up to retrofit the first computer program, in particular the coder module, on one or more vehicles (e.g. a customer fleet).

The first computer program and / or the second computer program, in particular a computer program product comprising the first computer program and / or second computer program, can be designed as an update of a previous computer program, which, for example, as part of a functional expansion, for example as part of a so-called “remote software update”. Parts of the computer program or the corresponding program code. The computer program product includes in particular an authorized access right to stored data of the computer program product.

It should be noted that the methods, devices and systems described in this document can be used both alone and in combination with other methods, devices and systems described in this document. Furthermore, any aspects of the methods, devices and systems described in this document can be combined with one another in a variety of ways. In particular, the features of the claims can be combined with one another in a variety of ways.

Claims (10)

Method (20) for transmitting information (I) from a vehicle (F) to a backend (B), in particular in connection with an emergency situation, comprising: - Determine (21) information (I) to be transmitted and then: - Vary (22), depending on the information to be transmitted (I): - a number (N) of messages (calls) to be sent by the vehicle (F, F1, F2, F3); and or - a time offset (ΔT2) between at least two, in particular a subnumber (M) of the (N) messages (call); and or - a pattern of at least three messages (call), whereby at least two of the messages (call) differ from the information (I) to be transmitted and in particular have the same content; - Evaluating (23) the number (N), the time offset (ΔT2) between two or more messages (call), and / or a pattern of at least three messages (call) in the backend (B); and - Conclusion (24) about the information to be transmitted (I) in the backend (B) depending on the result of the evaluation. Method (20) according to the Claim 1 , where, - varying (22) the number (N) of messages (call), the time offset Δt and / or the pattern of at least three messages (call) in the vehicle (F, F1, F2, F3) according to one in the vehicle (F, F1, F2, F3) or coding rule transmitted to the vehicle (F, F1, F2, F3) from the backend (B); and/or - evaluating (23) the number (N), the time offset (ΔT2) between two or more messages (call), and/or a pattern of at least three messages (call) in the backend (B) using one with the Coding rule in the vehicle (F, F1, F2, F3) corresponding decoding rule takes place. Method (20) according to the Claim 1 or 2 , whereby, - the information (I) to be transmitted is not added to the message (call) or is not transmitted with the message (call) or is not encoded in the message (call); and/or - no change in the size and/or format of the message (call); and/or - no change in the content, in particular payloads of a message (call); and/or - there is no delay in the receipt of the useful content of the message (call), which is determined in each case by the information (I) to be transmitted. Method (20) according to one of the preceding claims, wherein - the message (call) is an emergency message, in particular regarding an accident involving the vehicle (F); and/or - the information (I) to be transmitted identifies a status of one or more functionalities for at least partially automated driving of the vehicle (F), in particular relating to a time interval before and/or during the occurrence of the emergency situation of the vehicle (F). Method (20) according to one of the preceding claims, wherein, a conclusion is drawn from the at least one message (call) and the transmitted information (I): - whether and/or what is the temporal and/or causal connection to the functionality for at least partially automated driving of the vehicle (F); and or - there is an increased risk of an accident in one or more other vehicles (F1, F2, F3). Method (20) according to one of the preceding claims, wherein, depending on several messages (call) and the respective information to be transmitted (I), a statistical evaluation relating to a specific vehicle type, specific accident type and / or consequences of the accident of the vehicle (F, F1 , F2, F3) determined, and: be taken into account when operating the current vehicle fleet (F, F1, F2, F3); and or be taken into account when developing or updating new vehicles. Method (20) according to one of the preceding claims, comprising: - Receiving a message (call) transmitted by a vehicle (F, F1, F2, F3) in the backend (B); - Determine whether the message (call) is received by a vehicle (F, F1, F2, F3) that has an, in particular a specific, assignment rule for changing a number (N) of the vehicle (F, F1, F2, F3 ) messages to be sent (call) and/or a time offset (ΔT2) between at least two messages (call); and then: - Evaluating the respective information to be transmitted (I) depending on the information determined. Vehicle (F, F1, F2, F3) comprising a module for carrying out the method (20) according to one of Claims 1 - 6 . Backend (B) for receiving and evaluating the data from a fleet of vehicles (F1, F2, F3), the backend (B) being set up to carry out the method according to one of Claims 1 until 7 . Computer program product comprising a first computer program, wherein the first computer program is set up, when executed on a computing unit, according to one or more methods (20). Claims 1 - 7 and/or comprising a second computer program, wherein the second computer program is set up to be a computer program for executing the method (20) according to one or more Claims 1 - 7 , in particular to set up the first computer program in a vehicle (F1, F2, F3), in particular that has already been delivered.

Images