DE102023000839A1 - Vehicle alarm system and method for operating a vehicle alarm system - Google Patents

Abstract

The invention relates to a method for operating an alarm system (A) comprising a backend system (B) and an alarm device (F) which can be connected thereto, of a vehicle provided with an alarm detector. At least when an alarm condition is detected by the alarm detector, the alarming device (F) generates a query (M1, M2) with an associated challenge and sends it to the backend system (B). A query is answered by the backend system (B) with a response (M3, M4) that can be clearly assigned to the challenge. The alarm device (F) at least partially delegates the mitigation of the alarm state to the backend system (B) if a reliable connection between the alarm device ( F) and the backend system (B) is determined. The alarm device (F) emits optical and/or acoustic warning signals to mitigate the alarm condition, preferably only if an unreliable connection between the alarm device (F) and the backend system (B) is detected based on at least one query (M1, M2). it is determined that one of the at least one query (M1, M2) via a challenge respectively assignable answer (M3, M4) is not received or is not received within a predetermined time. The invention also relates to an alarm system (A) set up for carrying out this method.

Description

The invention relates to a method for operating an alarm system of a vehicle according to the preamble of claim 1 and an alarm system of a vehicle according to the preamble of claim 5.

The document U.S. 2020/0217942 A1 describes a method for detecting occupants inside a vehicle, comprising calculating an indicator for the strength of a currently received signal inside the vehicle, comparing such an indicator with a reference value and activating one or more vehicle systems depending on this comparison.

The document U.S. 2008/0077938 A1 describes a method for tracking the state of a session in a communication between a server system and a client system. During the session, application data is provided to the client system only if the client system has a valid state tracking value. The method includes providing a new value of state tracking information to the client system in a message. It further comprises calculating a value of state tracking information valid after transmission of a message using at least the new value transmitted in the message and a data value provided by the client system.

The invention is based on the object of specifying an improved method for operating an alarm system of a vehicle. This object is achieved with a method that has the features of claim 1.

The invention is also based on the object of specifying an improved alarm system for a vehicle. This object is achieved with an alarm system that has the features of claim 5.

Advantageous configurations of the invention are the subject matter of the dependent claims.

An alarm system of a vehicle comprises a backend system and an alarm device of a vehicle provided with an alarm detector that can be connected thereto. The alarm device is set up to emit visual and/or acoustic warning signals that can be heard in the area surrounding the vehicle.

The backend system can be designed as at least one server that offers one or more services in the form of cloud services or software-as-a-service (SaaS) services.

The alarm device is set up so that it can be connected to the backend system, in particular set up to use the services offered by this backend system.

In a method for operating such an alarm system, at least when an alarm condition is detected by the alarm detector, the alarm device generates a query with an assigned challenge and sends it to the backend system.

An alarm detector can be designed, for example, as a sensor that detects the presence of vehicle occupants, for example a child or an animal, in a locked vehicle based on movements and/or body heat and/or noises and then triggers an alarm condition.

Here and in the following, a challenge is to be understood as an identifier by means of which a query can be assigned and recognized. For example, a challenge can be embodied as a count of a counter of the alerting device, which is incremented each time a query is generated.

A query is answered by the backend system if successful (i.e. if there is a connection to the alarm device suitable for the transmission of messages, for example a connection switched via a mobile network) with a response that can be clearly assigned to the challenge. A clear assignment can be made possible, for example, by returning a counter reading sent to the backend system as a challenge.

According to the invention, the alarming device delegates the mitigation of the alarm state at least partially to the backend system if a reliable connection between the alarming device and the backend system is determined based on the queries and responses linked via an assigned challenge.

The mitigation of an alarm condition is to be understood here and in the following as the entirety of measures that eliminate and cancel the triggering condition of the alarm condition (e.g. trapped vehicle occupants) and/or contribute to its accelerated elimination (e.g. notify professional rescue services) and/or the consequences mitigate a situation characterized by the alarm condition (e.g. by turning on switching ventilation or air conditioning in the vehicle).

To mitigate the alarm status, the alarm device emits visual and/or acoustic warning signals if and preferably only if an unreliable connection between the alarm device and the backend system is determined on the basis of at least one query by the alarm device responding to at least one query a response from the backend system, which can be assigned to one of the at least one query based on a challenge, is not received or is not received within a predetermined period of time.

In other words: the alarm device determines an unavailability of the backend system by the fact that there are no answers to queries (which can be identified via the respective challenge and can be assigned to the answers).

For example, if queries directed to the backend system are not answered, are answered late or only partially with corresponding answers (i.e. can be assigned to the respective query based on the challenge), the connection between the alarm device and the backend system may be disrupted or unavailable of the backend system can be concluded. Mitigation measures delegated to the backend system must therefore be considered potentially ineffective.

By emitting optical and/or acoustic warning signals locally (i.e. effective in the vicinity of the vehicle) according to the invention, the robustness of the alarm system against failures of the backend system or the connection thereto, in particular against failures or faults in a mobile network for data transmission between the Alerting device and the backend system or compared to an incomplete coverage by such a mobile network improved. This improves the safety of vehicle operation, in particular the safety of the vehicle occupants.

At the same time, the at least partial delegation of the mitigation measures according to the invention means that an alarm condition can be resolved without local warning signals. This avoids unnecessary disturbance in the surroundings of the vehicle, for example from residents of nearby residential buildings.

Exemplary embodiments of the invention are explained in more detail below with reference to a drawing.

• 1 schematisch ein Sequenzdiagramm für die Übertragung von Abfragen und Antworten zwischen einem Frontend-System und einem Backend-System eines Alarmierungssystems.

It shows:

• 1 a schematic sequence diagram for the transmission of queries and responses between a front-end system and a back-end system of an alerting system.

1 shows a schematic sequence diagram for the transmission of messages M, M1 to M4 between a front-end system F and a back-end system B, which are connected to an alarm system A. In the present case, the front-end system F is embodied as an alarm device F of a mobile vehicle, not shown in detail, and includes a first and a second runtime instance R1, R2, which are provided by subsystems of this vehicle. Such subsystems can, for example, be programs that run on one or more control devices or similar, preferably programmable, processing units.

The backend system B comprises a third runtime entity R3 and a large number of other runtime entities R, which are not differentiated in more detail, which are provided as programs or program parts on one or more, usually stationary servers. The runtime instances R, R3 of the backend system B can, for example, be provided in parallel or alternately on different servers in the form of cloud services or software-as-a-service (SaaS) services using a load distribution algorithm, but apart from that they are location-based and in particular movable not connected to the vehicle.

For example, the first runtime entity R1 can be in the form of a program that is executed at predetermined intervals in the manner of a software watchdog. The second runtime entity R2 can be embodied as part of a protocol stack that is used for mobile communication between the vehicle and the backend system B across a system boundary G 1 is shown purely schematically.

The third runtime entity R3 assigned to the backend system B can be embodied as a part of this protocol stack that corresponds to the second runtime entity R2.

The first runtime entity R1 generates a first message M1, which includes a challenge, at regular intervals. In a particularly simple exemplary embodiment presented here, the challenge is formed by a count, ie: a non-negative natural number n. Each instance of the first message M1 generated by the first runtime instance R1 is then compared to the previously generated instance the first message M1 incremented counter reading attached. In other words: each instance of the first message M1 can be distinguished from other instances on the basis of the counter reading transmitted therein.

As an alternative or in addition to a counter reading, other challenge values that can be distinguished from one another can also be attached to the first message M1, for example a time stamp. In general, it is also sufficient if the distinguishability of challenge values is guaranteed over a sufficiently long period of time (explained in more detail below) or with a sufficient probability. For example, a cyclic counter can be used or a random number can be generated with a sufficient number of decimal or binary places to ensure sufficient differentiation.

After the transmission to the second runtime entity R2, the first message M1 is transformed by the latter into a second message M2.

In one in the upper part of 1 illustrated success scenario 1, this second message M2 is transmitted as a query M2 via a mobile data transmission protocol according to the agreed protocol stack to the third runtime entity R3 and then processed by the backend system B and, as will be explained below, answered.

Optionally, as in 1 only shown schematically and by way of example, for this purpose several runtime entities R, R3 of the backend system B exchange and process messages M with each other, which in 1 are not further differentiated, but which are typically designed differently.

Thus, the messages M exchanged between the runtime entities R, R3 of the backend system B can be implemented as function calls of a runtime entity R designed as a runtime library and accessible via a respective programming interface. Alternatively, the runtime instances R, R3 can also be implemented as services and/or as microservices. In this case, the messages M can be in the form of messages to service endpoints.

As a result of the processing in the backend system B, one of its runtime entities R, R3 (not necessarily the same third runtime entity R3 that received the second message M2 from the second runtime entity R2 of the frontend system F) a third message M3 is sent across the system boundary G to the front-end system F, in this case to its second runtime entity R2.

The third message M3 includes a response to the original challenge (here the counter reading represented by a non-negative natural number) in a suitable, i.e. readable and evaluable for the front-end system F, in particular in one that can be assigned to the challenge Shape. The third message M3 is therefore also to be understood as an answer M3 to the query M2 made to the backend system B with the second message M2.

In the simplest case, the value of the challenge can be returned to the front-end system F unchanged. However, it is also possible to return a challenge signed by the backend system B. This ensures that the second message M2 actually arrived at the backend system B and was not intercepted by an attacker. In addition, further information can be attached to the third message M3 sent back to the front-end system F, for example the time at which the second message M2 was received by the back-end system B.

The third message M3 received by the second runtime entity R2 is transformed into a fourth message M4, sent to the first runtime entity R1 and checked there.

A check is carried out to determine whether there is a stable and trustworthy connection between the front-end system F and the back-end system B. For this purpose, the value of the challenge sent to the backend system B in the query (i.e. the first message M1 and subsequently in the second message M2 generated therefrom) (here: the counter reading transmitted as a number n) is compared with the value in the response ( that is to say: the value transmitted in the third message M3 and subsequently in the fourth message M4) generated therefrom is compared. For this is in 1 A first message M1 is merely shown as an example as a function call TrRqPush_CPD, to which a number n is passed as an argument. In this way, queries are determined to which no response or only an impermissibly late response can be assigned.

For example, the latency of the response, ie the time difference between sending the first message M1 and receiving the fourth message M4, can be determined and compared to a predetermined maximum latency. If the maximum latency exceeds for a certain, likewise predetermined number of instances of the first message M1 sent in succession and/or sufficiently often in a predetermined time interval steps, the connection between the front-end system F and the back-end system B is considered unreliable.

The selection of the challenges (e.g. the upper limit for a cyclic counter or the number of decimal or binary places of a generated random number) is designed in accordance with the rules of this test in such a way that an incorrect assignment of an answer is reliably or almost certainly excluded. If, for example, the exceeding of the maximum latency relates to a predetermined number of consecutive queries M1, M2, then the upper limit of a cyclic counter must be greater, preferably several times greater, than this predetermined number.

Analogously, a generator for challenges designed as random numbers must be designed in such a way that the probability of generating several random numbers of the same value within such a predetermined number of consecutively generated random numbers or within a certain time interval is sufficiently low, measured against the desired reliability of the connection between the Backend system B and the frontend system F.

In addition or as an alternative, further or different rules can also be used as a basis for the check. For example, the challenge values transmitted back can be used to check whether the order of the responses arriving at the front-end system F (i.e. the instances of the fourth message M4) matches the order of the queries going out there (i.e. the instances of the first message M1 ) matches. Likewise, queries that have failed (that is to say: not answered by a corresponding fourth message M4) can be counted and related to a predetermined period of time or to a predetermined number of queries. Of course, further data can also be evaluated, which were additionally attached to the third message M3, for example an error code, a system health status or the like.

In the lower part of 1 illustrated failure scenario 2, the connection between the front-end system F and the back-end system B is disrupted, so that the second and/or the third message M2, M3 is not or will not be transmitted. The rest of the process corresponds to the procedure already explained with reference to success scenario 1.

If, in the case of success scenario 1, the reliability of the connection is successfully checked, the handling of error or alarm states on the vehicle can be delegated to the backend system B.

For example, a front-end system F designed as a vehicle can be provided with a sensor system that recognizes an occupant accidentally locked in the vehicle, for example a child or an animal, and reports an alarm status accordingly. In the case of a successfully verified connection to a backend system B according to success scenario 1, the alarm status can be reported there. The message is analogous to the transmission of the second message M2 to the backend system B, which has already been described, but is shown in FIG 1 not considered in detail.

In response to an alarm condition reported in this way, the backend system B can initiate mitigation measures, for example notifying a person assigned to the vehicle via their mobile phone. This means that the triggering of optical and/or acoustic warning signals directly on the vehicle can be avoided. This avoids unnecessary stress both in the vehicle environment and the enclosed vehicle occupants.

In certain situations, however, the connection to the backend system B can be disrupted or even interrupted, for example when the vehicle with the frontend system F is on the edge or outside the coverage area of the mobile network. Technical faults, for example in the transmitting/receiving system, or software errors within the first or second runtime entity R1, R2 can also impair the connection to the backend system B.

If such an impairment is determined using the parameters and rules described above as an example (e.g. no responses M3, M4 to a predetermined number of sent queries M1, M2 or over a predetermined period of time), the emission of warning signals to the vehicle surroundings is activated. Appropriate rescue or protective measures can thus be initiated even if the backend system B is unavailable.

In one embodiment, the front-end system F can determine a status of the connection to the back-end system B (for example one of the values “available”, “not available” or “unreliable”) and take it into account when escalating the alarm or error status.

Reference List

A

alerting system

B

backend system

f

Front-end system, alerting device

G

system boundary

M

News

M1 to M4

first to fourth message

M1, M2

query

M3, M4

Answer

R

runtime instance

R1 to R3

first to third runtime instance

1

success scenario

2

failure scenario

QUOTES INCLUDED IN DESCRIPTION

This list of documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• US 2020/0217942 A1 [0002]
• US 2008/0077938 A1 [0003]

Claims (5)

Method for operating an alarm system (A) comprising a backend system (B) and an alarm device (F) connectable thereto of a vehicle provided with an alarm detector, the alarm device (F) being set up to emit optical and/or acoustic warning signals, characterized in that that - at least when an alarm condition is detected by the alarm detector, the alarming device (F) generates at least one query (M1, M2) with an associated challenge and sends it to the backend system (B) and - from the backend - System (B) is answered with a response (M3, M4) that can be clearly assigned to the challenge and - the alarm device (F) at least partially delegates the mitigation of the alarm condition to the backend system (B) if based on the respective assigned challenge interlinked at least one query (M1, M2) and response (M3, M4) a reliable connection between the alarm device (F) and the backend system (B) is determined and - the alarm device (F) for mitigating the alarm status optical and / or emits acoustic warning signals, preferably only if an unreliable connection between the alarm device (F) and the backend system (B) is determined on the basis of at least one query (M1, M2) in that one of the at least one query (M1, M2) a response (M3, M4) that can be assigned in each case via a challenge is not received or is not received within a predetermined time. procedure after claim 1 , characterized in that the challenge is formed as a continuously incremented counter and/or time stamp and/or random number. Method according to one of the preceding claims, characterized in that an unreliable connection between the alarm device (F) and the backend system (B) is determined if, in response to a query (M1, M2), no response is sent to the alarm device ( F) the response (M3, M4) transmitted back can be assigned. Method according to one of the preceding claims, characterized in that escalating measures for mitigating an alarm state take into account whether a reliable or an unreliable connection between the alarm device (F) and the backend system (B) was determined. Alarm system (A) comprising an alarm device (F) with an alarm detector and a backend system (B), characterized in that the alarm device (F) and the backend system (B) for exchanging messages (M, M1 to M4) are set up via a mobile data network and are set up in each case by means of at least one computer-implemented runtime entity (R, R1 to R3) for carrying out a method according to one of the preceding claims.

Images