DE102013214018A1 - Vehicle system and method for automated control of at least one safety-relevant function of a vehicle - Google Patents

Abstract

System for a vehicle (1), in particular a land vehicle, comprising a mobile requesting device (2), and a delivery device (10). In this case, the mobile request device (2) has a request element (21), an authentication element (22) and a transmission module (23). The delivery device (10) has a receiving module and a control module (101). In this case, the delivery device (10) is arranged in the vehicle (1). The request element (21) is set up to provide a corresponding request information (211) to the transmission module (23) for a safety-relevant request (210) from a user. The authentication element (22) is arranged to provide authentication information (221) to the transmission module (23). The transmission module (23) is set up to provide the request element (21) with both the provided request information (211) and the provided authentication information (221) as authenticated request information (212) to the executing device (10) upon provision of request information (211) by the request element (21). to send. The receiving module (100) is set up to receive the authenticated request information (212), to validate (V) the authentication information (221) contained in the authenticated request information (212), and to authenticate the authentication information (221) in the authenticated request information (221). 212) to the control module (101) to forward request information (211). The control module (101) is arranged to execute the request information (211) automatically.

Description

The present invention relates to a vehicle system and method for automated control of at least one safety-relevant function of a vehicle.

According to the current state of the art, it is possible to control individual vehicle systems, which are not directly related to the guidance of a vehicle, by remote control, for example by key remote control, for example access functions such as a central locking or a luggage compartment or comfort functions such as windows, convertible top, Stand air conditioning or parking heater.

In many vehicles, the vehicle key also contains part of the immobilizer.

In all these cases, however, the actual driving / moving of the vehicle does not remain remotely controllable.

For the sake of theft protection exists for today's remote controls, such as in the vehicle key, the need for cryptographic protection. This is typically realized by means of symmetric or asymmetric encryption / signing.

Furthermore, the radio link of such remote controls against falsifications, for example by means of checksums / CRC / signatures secured. This can serve both the robustness and a further increase in the security of the transmission.

According to the current state of the art, there are many functions / systems in vehicles that are safety-relevant, in the sense of protection against unjustifiable risks to life and limb. These are according to the prior art, for example, by standards such IEC 61508 or ISO 26262 , defined, developed and secured. In the case of many such safety-relevant proofs, the mechanical penetration available independently of the supporting system, and thus ultimately the presence of a capable driver on board the vehicle, play an essential role.

At present, it is not possible to automatically provide such technical safety-related functions for controlling the vehicle outside of the vehicle, for example remotely controllable, as, for example, as a remote control for guiding a car by a driver / operator not on board.

Therefore, it would be desirable to provide a way to provide a safety-related function / system, in terms of protection against unacceptable risks to life and limb, automated and / or remotely controllable, without having to have on board the vehicle an operable driver / operator.

It is an object of the invention to provide a solution for an automated and / or remotely controllable safety-related function / system, in the sense of protection against unjustifiable risks to life and limb, without having to have on board the vehicle a capable driver / operator ,

The object is achieved by a system according to the main claim, two devices according to independent claims and a method according to a sibling claim.

The subject of the main claim relates to a system for a vehicle, in particular a land vehicle, comprising a mobile request device, and a Ausführvorrichtung. In this case, the mobile request device has a request element, an authentication element, and a transmission module. The delivery device has a receiving module and a control module, wherein the delivery device is arranged in the vehicle. The request element is set up to provide corresponding request information to the transmission module in response to a safety-relevant request from a user. The authentication element is arranged to provide authentication information to the transmission module. The sending module is configured to send both the provided request information and the provided authentication information as authenticated request information to the executor upon provision of request information by the requesting element. The receiving module is configured to receive the authenticated request information, to validate the authentication information contained in the authenticated request information, and to forward the request information contained in the authenticated request information to the control module in case of validity of the authentication information. Furthermore, the control module is set up to automatically execute the request information.

A "motor vehicle" in the sense of the invention means an engine or turbine-driven land vehicle. In particular, a land vehicle such as an automobile or two-wheeler is meant.

"Safety-relevant" in the sense of the invention means relevant to the protection against unacceptable risks to life and limb.

By contrast, "security-relevant" in the sense of the invention means relevant to access protection, protection against intruders, protection against data corruption and / or data manipulation and the like.

A "safety-relevant requirement" in the sense of the invention meant a requirement for a safety-relevant function / system of a vehicle.

A "mobile request device" within the meaning of the invention means a device which is suitable to be operated on the move and to receive a safety-relevant request to a vehicle and forward it to this, wherein the safety-relevant requirement by the mobile request device can also be modified. In particular, a mobile request device may be a remote control, for example a remote control integrated in a vehicle key.

A "request element" in the sense of the invention means in a simple case a button, a switch, a button and the like, which, when actuated by a user, for example a vehicle operator, provides request information in the mobile request device. However, in a more complex case, the request element may also be an adjuster, knob, touch pad, and the like, which allows for more complex user requests.

A "request information" in the sense of the invention means an information which is obtained based on a corresponding safety-relevant requirement. In the simplest case, the request information is the safety-relevant requirement itself. However, it can also contain further information, for example for enabling a security-relevant transmission of the request information.

An "executing device" in the sense of the invention means a device arranged in the vehicle, which is set up to receive a safety-relevant requirement for the vehicle from a mobile requesting device.

An "authentication information" in the sense of the invention means information indicating that the request information sent / received with the authentication information is authentic, and thus valid. This may be necessary, for example, if it must be ensured that not every delivery device within the meaning of the invention may receive a safety-relevant request from any request device in the sense of the invention.

A "module" in the sense of the invention means a part of a device, this part is preferably integrated in the corresponding device. A module can itself be a corresponding device. A module can also be software or part of a software.

A "transmission module" in the sense of the invention means a module or a device which is arranged in the mobile request device and is set up to send the request information and the authentication information together. This can be done together by sending the two pieces of information bundled together as one piece of information or one by one. In both cases, both information can also be modified, for example, in order to enable the transmission of the security-relevant information.

A "control module" in the sense of the invention means a module or a device which is set up to control a safety-relevant function, a safety-relevant device and / or a safety-relevant system on the basis of a safety-relevant requirement. The safety-relevant function, the safety-relevant device and / or the safety-relevant system can also be controlled automatically on the basis of the safety-relevant requirement.

A "function" in the sense of the invention means a functional part of a vehicle, for example a driving operation of a chassis and / or the placement of the wheels. A function can also be a complex process involving several functional parts of a vehicle, which can be executed, controlled, operated and / or regulated simultaneously or in chronological order.

"Automated" in the sense of the invention means a controlled and / or regulated acquisition and / or intervention in a safety-relevant function of a vehicle, without it being necessary for controlling and / or rules to instructions by a driver / operator / user.

The teaching according to the invention achieves the advantage that the system according to the invention makes it possible to provide a remote-controllable control of a safety-relevant function / system, in the sense of protection against unjustifiable risks to life and limb, without affecting itself Board of the vehicle must be a capable driver / operator. In this case, the remote-controlled taxes can also be automated.

The subject of a first independent device claim relates to a mobile request device for a system according to the main claim. In this case, the mobile request device is a remote control, in particular a radio remote control, preferably a vehicle key or a mobile communication device and has a request element, an authentication element and a transmission module. In this case, the request element is set up to provide request information to the transmission module in response to a safety-relevant request from a user. The authentication element is configured to provide authentication information, and the transmission module is configured to send both the provided request information and the provided authentication information as authenticated request information to the executor upon provision of request information by the request element.

The "mobile request device" within the meaning of the invention can thus also be a remote-controlled smartphone.

The teaching according to the invention achieves the advantage that with the device according to the invention a remotely controllable control of a safety-relevant function / system, in the sense of protection against unacceptable risks to life and limb, can be initiated without having an able-bodied driver on board the vehicle / Operator must be located.

Another advantage of the teaching of the invention is that so that the request device can be designed so that not the entire request device explicit safety requirements, such as those in standards such as IEC 61508 or the ISO 26262 described, must inherit.

The subject matter of a further independent device claim relates to a delivery device for a system according to the main claim.

In this case, the execution device has a receiving module and a control module. The executing device is adapted to be used in the vehicle. The receiving module is configured to receive an authenticated request information, to validate an authentication information contained in the authenticated request information and to forward a request information contained in the authenticated request information to the control module in the case of validity of the authentication information. The control module is set up to automatically execute the request information.

The "control module" according to the invention can be firmly integrated into the vehicle. However, it is also conceivable that it is a module which can be subsequently integrated into the vehicle so that the vehicle can be retrofitted therewith.

"Validate" in the sense of the invention means to determine whether an authentication information contained in an authenticated request information is valid, whereby a conclusion is possible that a request information also contained therein valid, d. H. neither manipulated nor falsified, and thus is genuine.

The teaching according to the invention achieves the advantage that with the device according to the invention a remotely controllable control of a safety-relevant function / system, in the sense of protection against unacceptable risks to life and limb, can be provided without a capable driver on board the vehicle / Operator must be located.

The subject matter of a non-independent method claim relates to a method for the automated control of at least one safety-relevant function of a vehicle for a system according to the main claim, the method comprising: receiving an authenticated request information, validating an authentication information contained in the authenticated request information, forwarding the in the authenticated request information containing request information and the result of validating the authentication information to a control module. The method has for the control module, if the result of the validation of the authentication information is negative and a safety-relevant function of the vehicle has already been adopted: Transferring the acquired safety-relevant function in a safe state, releasing the adopted safety-relevant function, reject the request information. Furthermore, the method for the control module, if the result of validating the authentication information is negative and no safety-relevant function of the vehicle is taken: Rejecting the request information. In addition, the procedure for the control module, if the result of validating the authentication information is positive: If a safety-relevant function of the vehicle is already adopted: Transferring the acquired safety-relevant function in a safe state and releasing the adopted safety-relevant function. Furthermore, the method for the control module, regardless of whether a safety-relevant function of the vehicle has already been adopted: Determining on the basis of the request information, which safety-relevant function of the vehicle is to be adopted, transferring the safety-relevant function to be adopted in a safe state if the safety-relevant function can not be transferred to a safe state, rejecting the execution of the request information, and if the safety-relevant function is transferred to a safe state, taking over the safety-relevant function and executing the request information.

A "safe state" in the sense of the invention means a state with regard to the safety-relevant function / system / module to be controlled and thus any further associated safety-relevant functions / systems / modules of which no unacceptable risk for body and limb Life can go out. The safe state of the function / system / module can be, for example, an initial ground state. If the safety-relevant requirement information relates, for example, to the chassis of the motor vehicle, then a safe state with respect to the chassis module can be that the vehicle is stationary and the wheels of the chassis module are all aligned in their basic position, ie, for example, all in alignment for straight-line operation, the engine is stationary or rotated in its idle speed, no gear is engaged and the hand brake and / or the brake pedal are actuated, respectively, the vehicle is in automatic transmission with respect to the transmission in parking position.

"Executing the request information" in the sense of the invention can be an execution of only one safety-relevant function / system / module, but it can also be affected by the execution of several safety-relevant function / system / module.

The teaching according to the invention achieves the advantage that with the method according to the invention a remotely controllable control of a safety-relevant function / system, in the sense of protection against unacceptable risks to life and limb, can be provided without a capable driver on board the vehicle / Operator must be located.

A further advantage of these teachers according to the invention is that no safety-relevant function / system, in the sense of protection against unjustifiable risks to life and limb, can be adopted and carried out if it is not ensured that the vehicle performs this safety-relevant function / System does not run such a risk. This assumes a deterministic state before it can be started with an automated control of a previously described safety-relevant function / system.

Hereinafter, further exemplary embodiments of the system, the devices and the method will be explained.

According to a further exemplary embodiment, the system has the control module having a safety-relevant module. In this case, the automated execution of the request information by the control module on the basis of the request information, the safety-relevant module is instructed to take at least one safety-relevant function of the vehicle to automatically execute the request information. The control of the adopted safety-relevant function of the vehicle is transferred to the safety-relevant module.

This embodiment has the advantage that the control of a safety-relevant function of the vehicle can be taken over by the execution device.

According to a further exemplary embodiment, the system indicates that the safety-relevant function is defined as a function according to at least one safety standard from the selection of the safety standards IEC 61508 . ISO 26262 , a safety standard that is stricter than these two, a safety standard that develops at least one of the aforementioned standards and a safety standard that corresponds to one of the aforementioned safety standards.

This embodiment has the advantage that it provides a solution based on safety-relevant standards.

According to a further exemplary embodiment, the system further comprises that the request information, the authentication information and the authenticated request information each have a complexity that is sufficiently high that they are not randomly generated with a defined probability and are protected against falsification. The specified probability results from the safety standard used for the safety-relevant standard. The protection against adulteration is preferably by means of a checksum method, a CRC method, a signature method, an encryption method or a combination of at least two of the aforementioned methods vornehmbar.

This refinement has the advantage that a solution is thus provided in which the transmission path of the safety-relevant request from the mobile request device to the executing device and / or a manipulation attempt as source for a false safety-relevant request can be excluded.

According to a further exemplary embodiment, the system has the fact that the safety-relevant requirement is a parking request with respect to a forward-oriented parking process of the vehicle or a parking requirement with respect to a rear-facing parking operation of the vehicle. The adopted safety-relevant function of the vehicle is in the case of a parking request, a forward autonomous driving of the vehicle and in the event of a Ausparkanforderung, a backward autonomous driving of the vehicle. In this case, the autonomous driving may have steering movements of the vehicle.

"Forward" within the meaning of the invention means an orientation in the direction of the vehicle front side, whereas "directed backwards" in the sense of the invention means an orientation in the direction of the vehicle rear side.

A "forward parking" within the meaning of the invention means a parking operation in a parking bag or parking space, which is arranged in the longitudinal direction of the vehicle, the vehicle moves forward in the parking bag or parking space, in particular where the vehicle without rear maneuvering in the parking bag or parking space moves.

A "reverse parking operation" in the context of the invention means a parking operation in a parking bag or parking space, which is arranged in the longitudinal direction of the vehicle, the vehicle moves backwards in the parking bag or parking space, in particular wherein the vehicle without forward maneuvering in the parking bag or parking space moves.

"Autonomous driving" within the meaning of the invention means an independent driving a vehicle without a user makes the driving and steering movements of the vehicle. In particular, the independent driving of a vehicle is meant without a driver must be on board the vehicle.

This embodiment has the advantage that a forward-directed parking process of a vehicle and a rear-facing parking operation of a vehicle are each made possible automatically.

This also has the advantage that the Vorwärteinparken a vehicle in a parking space / parking bag can be made possible, in which the driver after parking could not or only with difficulty get out of the vehicle.

This has the additional advantage that the backward parking out of a vehicle from a parking space / parking bag can be made possible, in which the driver in the parked state of the vehicle could not or only with difficulty get out of the vehicle.

According to a further exemplary embodiment, the mobile request device has the fact that the authentication element has to be activated by the user so that the authentication element provides valid authentication information as authentication information to be sent.

In this way it can be ensured that a safety-relevant requirement is not triggered by an unintentional actuation of a safety-relevant requirement element of the mobile request device. This could otherwise be done, for example, by dropping the mobile request device, or if the mobile request device is in a driver's bag, for example, such inadvertent triggering could be triggered by shaking motions as the driver walks with the bag.

The authentication element can be done, for example, by execution in the form of a so-called deadman switch, which means that the authentication element would have to be triggered simultaneously with the request element. It may also mean that the authentication element would have to be triggered during the entire automated safety-relevant process, or the like.

This embodiment has the advantage that the mobile requesting device can be secured against unintentional triggering of a safety-relevant requirement.

According to a further exemplary embodiment, the mobile request device has a stop element. In this case, the stop element is set up to provide stop information as request information to the transmission module on request of the user.

A "stop element" in the context of the invention is an element of the mobile request device, which, when actuated, a Stop information is provided to stop an active safety-relevant automated process on a safety-related function of the vehicle. Stopping the automated process on the safety-relevant function of the vehicle is preferably carried out directly, ie within a time that is sufficiently short in accordance with the above-mentioned safety-relevant standards.

In one embodiment, the stop element may also be the authentication element or a part thereof, in particular if the authentication element has to be actuated at the safety-relevant function of the vehicle during the entire process duration of the automated process.

This refinement has the advantage that the driver / driver / operator / operator can intervene in order to be able to stop the automated process at the safety-relevant function of the vehicle, for example at a danger identified by it, which for the system, the vehicle , the automatically controlled safety-relevant module and / or the execution device is not recognizable or not recognized.

According to a further exemplary embodiment, the method has, if the request information is a stop information and a safety-relevant function of the vehicle has already been adopted: transferring the acquired safety-relevant function to a safe state, regardless of the result of validating the authentication information, and Release of the adopted safety-relevant function.

This refinement has the advantage that in the case of receiving a stop information, the acquired safety-relevant function of the vehicle can be directly transferred to a safe state.

This refinement thus also has the advantage that in the case of an intervention by a driver / driver / operator / operator, the automated process can be stopped at the safety-relevant function of the vehicle.

The invention thus makes it possible to automatically control safety-relevant functions of vehicles without having to give up the protection against unjustifiable risks to life and limb.

The invention will be explained in more detail with reference to the figures, show in these

1 a schematic representation of a proposed system for a vehicle for the automated control of at least one safety-relevant function of a vehicle according to an exemplary embodiment of the invention;

2 a schematic representation of a proposed system for a vehicle for the automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention;

3 a schematic representation of a proposed method for a vehicle for the automated control of at least one safety-relevant function of a vehicle according to an exemplary embodiment of the invention;

4 a schematic representation of a proposed system for a vehicle for the automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention;

5 a schematic representation of a proposed system for a vehicle for the automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention;

6 a schematic representation of a proposed system for a vehicle for the automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention; and

7 a schematic representation of a proposed system for a vehicle for the automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention;

Before describing embodiments of the invention in more detail below, it should first be noted that the invention is not limited to the described components or the described method steps. Furthermore, the terminology used is not a limitation, but has only exemplary character. Insofar as the singular is used below in the description and the claims, the plural is included in each case, unless the context explicitly excludes this.

1 shows a schematic representation of a proposed system for a vehicle for automated control of at least one safety-relevant function of a vehicle according to an exemplary embodiment of the invention.

In the case of remote control of safety-relevant functions / systems in the vehicle, there are requirements for safety and reliability in addition to the requirements for robustness and security that are already known today for the entire remote control, ie transmitter and receiver side.

For example, the erroneous activation of a remote-controlled safety-relevant function due to errors in the remote control transmitter must be sufficiently excluded or hedged.

These safety requirements, for example, must be developed and safeguarded by the entire remote control, ie transmitter and receiver side, according to a safety standard such as the current one IEC 61508 or in the automotive sector currently the ISO 26262 be fulfilled.

However, this "classical" approach leads to considerable requirements, in particular to the remote control transmitter, which are to be regarded as problematic, for example in the field of SW development process and in terms of quantitative failure rates with today's "simple" key remotes.

For example, typical solutions used in safety such as the redundant processing of safety-relevant input signals in key remote controls are subject to strict limits due to the installation space and power consumption alone.

It shows 1 a system for a vehicle 1 , in particular a land vehicle, comprising a mobile request device 2 and an expander 10 , In this case, the mobile request device 2 a requirement element 21 , an authentication element 22 and a transmission module 23 on. The delivery device 10 has a receiving module 100 and a control module 101 on. In this case, the Ausführvorrichtung 10 in the vehicle 1 arranged, the request item 21 is set up to meet a safety-related requirement 210 a user a corresponding request information 211 to the transmitter module 23 to provide the authentication element 22 is set up to provide authentication information 221 to the transmitter module 23 provide, and the transmission module 23 is set up to provide request information 211 by the request element 21 both the provided request information 211 as well as the provided authentication information 221 as an authenticated request information 212 to the expander 10 to send. The receiving module 100 is set up to authenticate the request information 212 to receive that in the authenticated request information 212 containing authentication information 221 to validate V. and validity of the authentication information 221 those in the authenticated request information 212 contained request information 211 to the control module 101 forward. The control module 101 is set up to request information 211 run automatically.

2 shows a schematic representation of a proposed system for a vehicle for automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention.

It shows 2 an exemplary system extension of the in 1 shown exemplary system, wherein the control module 101 a safety-relevant module 1010 and wherein the automated execution of the request information 211 through the control module 101 has that on the basis of the request information 211 the safety-relevant module 1010 is instructed, at least one safety-relevant function 11 of the vehicle 1 to take over the request information 211 automated, and taking control of the inherited safety-relevant function 11 of the vehicle 1 to the safety-relevant module 1010 passes.

Further shows 2 an example of a mobile request device 2 for a system according to the invention, wherein the mobile requesting device 2 a remote control, in particular a radio remote control is, preferably a vehicle key or a mobile communication device. The requesting device 2 has a requirement element 21 , an authentication element 22 and a transmission module 23 on. Here is the requirement element 21 set up to a safety-relevant requirement 210 a user's request information 211 to the transmitter module 23 to provide the authentication element 22 is set up to provide authentication information 221 provide, and the transmission module 23 is set up to provide request information 211 by the request element 21 both the provided request information 211 as well as the provided authentication information 221 as an authenticated request information 212 to the expander 10 to send.

Further shows 2 that the authentication element 22 activated in this example by the user 220 must be, so that the authentication element 22 a valid authentication information 221 as authentication information to be sent 221 provides.

In addition, the mobile request device 2 out 2 exemplarily a stop element 24 on. Here is the stop element 24 set up to stop information at the request of the user 241 as requirement information 211 to the transmitter module 23 provide.

3 shows a schematic representation of a proposed method for a vehicle for the automated control of at least one safety-relevant function of a vehicle according to an exemplary embodiment of the invention.

It shows 3 By way of example, a method for the automated control of at least one safety-relevant function 11 of a vehicle 1 for a system according to the invention. The method has hereby:
Receiving an authenticated request information 212 Validate one of the authenticated request information 212 contained authentication information 221 Forward the in the authenticated request information 212 contained requirement information 211 and the result E of validating the authentication information 221 to a control module 101 , In this case, the method for the control module 101 on:
If the result E of the validation V of the authentication information 221 is negative and already a safety-relevant function 11 of the vehicle 1 is taken over:
Transfer of the adopted safety-relevant function 11 in a safe state S, enable F of the adopted safety-relevant function 11 , and reject R of the request information 211 , Further, if the result E of validating V is the authentication information 221 is negative and no safety-relevant function 11 of the vehicle 1 is taken over:
Reject R of the request information 211 ,

Otherwise, if the result E of the validation V of the authentication information 221 positive is:
If already a safety-relevant function 11 of the vehicle 1 is taken over:
Transfer of the adopted safety-relevant function 11 in a safe state S, and enable F of the adopted safety-relevant function 11 ,

Furthermore, regardless of whether already a safety-relevant function 11 of the vehicle 1 is taken over:
Determining based on the request information 211 , which safety-relevant function 11 of the vehicle 1 to be transferred, transfer of the safety-relevant function to be adopted 11 in a safe state S. If the safety-relevant function 11 can not be transferred to a safe state S:
Decline R the execution of the request information 211 ,

If the safety-relevant function 11 is transferred to a safe state S:
Acceptance of the safety-relevant function 11 and
Execute X the request information 211 ,

4 shows a schematic representation of a proposed system for a vehicle for automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention.

It shows 4 a transmitter / receiver system: a safety-relevant requirement 210 of a user, hereafter also called user input "BE", is part of 21 . 23 a mobile requesting device 2 , which subsequently also sender logic 21 . 23 or logic 21 . 23 is called by means of authentication information 221 in a corresponding authenticated request information 212 , hereinafter also referred to as "SD", which contains BE in coded form, that is: SD = f (BE). For example, f (BE} can be a
simple coding, such as SD = BE or SD contains, for security reasons, for example, even more information such as the identification of the sender or checksums, such as a Cyclic Redundancy Check "CRC" or a sequence counter. At the receiving end will be in parts 100 . 101 the expander 10 , also follow evaluation logic 100 . 101 from the received SD determines the user input BE, that is: BE = f ^-1 (SD), and the intended action is executed.

The approach according to the invention allows the switching on and off of safety-relevant functionalities, for example by means of a mobile request device 2 , below also remote control 2 called, for example, by key remote control 2 without the entire electronics or even just the microcontroller in the remote control transmitter 23 must inherit explicit safety requirements.

Here are the following considerations:
Analogous to today in the vehicle 1 The driver, who has the ultimate responsibility for the entire vehicle, should be the remote control 2 operating "operator" the ultimate responsibility over the remote-controlled functions 11 receive and / or retain.

A first safety requirement is therefore that the system turns ON a remote-controlled safety-relevant function 11 must be able to prevent without operator desire.

It is also assumed that a remote-controlled safety-relevant function 11 in the OFF mode represents a safe state S with regard to safe eating. Therefore, a second safety requirement is that the system requires an operator to turn off a remote safety related function 11 must recognize and implement by the safe state S is taken.

Since in this case it may happen that the operator may no longer have mechanical access, the system must also be designed such that in all situations and in particular also in the event of incorrect operation by the operator an uncontrolled stay or a change to a non-safe state Regarding Safetyness is prevented. In case of doubt, the safe state S is to be assumed with regard to safety ness. This is a third safety requirement.

An approach proposed according to the invention provides for the following to fulfill the first safety requirement:
In the transmission module 23 the mobile request device 2 , below also remote control transmitter 23 called, there is an authentication information 221 , hereinafter also secret "G" called, which of the Ausführvorrichtung 10 , below also recipients 10 called, is expected to the remote-controlled safety-relevant function 11 Turn ON. This secret G must be so complex that with reasonable probability is ruled out that an element in the chain transmitter 23 , Transmission link, receiver 10 and evaluation logic 100 . 101 that secret G, even in an error case, can generate randomly. The secret G can be designed so that the entire transmitter-side scope does not have to inherit explicit safety requirements. This is a significant advantage of the invention.

Furthermore, the secret G may not be transmitted on the transmitter side by operator security inputs, such as by activating or deactivating a stop element 24 Can be "activated". The secret G can be evaluated on the receiver side. Only when the correct secret G is detected does the receiver control 10 the safety-relevant functionality 11 of the vehicle 1 at.

The inventive approach provides in a further exemplary embodiment for fulfilling the second safety requirement that the mobile request device 2 , below also remote control transmitter 2 called, must contain a mechanism that is safe the remote-controlled safety-relevant function 11 Turns off as soon as the operator takes back the security entries. In the sense of safety, even in the event of an error, it is sufficiently probable to ensure that the secret can be deactivated when the operator withdraws the safety inputs.

Limits for the above "reasonable probabilities" may vary depending on safety relevance. They can be derived, for example, from specifications in the safety standards. For example, beats ISO 26262 for ASIL C a value of <= 1E-7 per hour of operation.

According to the invention may also be provided to meet the third safety requirement that the safety inputs transmitter side must be designed so that in typical incorrect operation situations such as when the remote control 2 is automatically dropped as a "remote safety-related feature 11 OFF "is interpreted. This can be done, for example, by suitably designing the stop element 24 happen.

According to the invention may also be provided to meet the third safety requirement that the safety inputs transmitter side must be designed so that in typical operating conditions, such as, for example, that the remote control 2 unintentional "inputs" in your pocket 210 and thus a safety-relevant function 11 with sufficient probability that inadvertently the secret G is "activated".

As a further exemplary embodiment includes the remote control 2 a safety circuit comprising a stop element 24 , which is a safety switching element 24-2 and a reset circuit 24-1 for the logic 21 . 23 and an authentication element 22 , below also safety logic "SichLogik" 22 called.

The remote control 2 In this case, it is also not possible to include inputs that are relevant to safety, such as the opening of the boot. If the user wants to make such an input that is not to be protected, then the transmitter side behaves as mentioned above, since the safety switching element 24-2 is not actuated, for example applies in this case for the safety switching element 24-2 of the stop element 24 Safety switching element = 1, and thus is SichLogik 22 not active.

If SichLogik 22 is not active, so the safety switching element 24-2 is equal to 1, then the logic can 21 . 23 the date SD only without G send, that is, SD = f (BE). This is recognizable on the receiver side, and the receiver 10 can only control those actions that are not to be secured User inputs correspond to BE. Safety switch element = 1 designates that the reset circuit 24-1 a current leads, whereas safety switching element = 0 indicates that the reset circuit 24-1 no electricity.

The task of SichLogik 22 it is, one of the logic 21 . 23 contain unknown and sufficiently complex secret G, which is used to secure security-relevant user input 210 is used.

This can be the SichLogik 22 for example, be a simple memory. The SichLogik 22 however, it may also be a more complex circuit, such as a microcontroller, ASIC, and the like. The SichLogik 22 is only active if the safety switching element 24-2 is equal to 0. In 4 For example, the connection to the power supply of SichLogik 22 over the way safety switching element 24-2 equal to 0 are realized.

• – die Komplexität von G bleibt erhalten;
• – empfängerseitige Prüfung auf Verwendung des korrekten G;
• – die Information über BE bleibt erhalten beziehungsweise ist empfängerseitig rekonstruierbar.

Only if SichLogik 22 is active, "knows" the logic 21 . 23 the secret G, for example because the activated SichLogik 22 the secret G to logic 21 . 23 sent or because of the logic 21 . 23 the secret G of SichLogik 22 he asks. If SichLogik 22 is not active, "knows" the logic 21 . 23 the secret G is not. In the case of user entries to be secured 210 the user must enter the corresponding entries via BE 210 and the safety switching element 24-2 actuate. This becomes the SichLogik 22 active and the logic 21 . 23 can about the secret G 221 feature. In this case, BE 210 with the help of G 221 in a date to be sent SD 212 converted which BE 210 and G 221 in coded form, that is SD = f (BE, G). Each function f (BE, G) is suitable if the following properties of the coding are fulfilled:

• - the complexity of G is preserved;
• - receiver-side check for the use of the correct G;
• - The information about BE is retained or can be reconstructed on the receiver side.

A simple example is appending G to BE (SD = f (BE, G) = BEoG):
For example, if BE consists of the binary word 1010 and G is of the binary word 10011001, SD = 101010011001 would be in this case.

You can also use a more complex encoding:
For example, BE might be in logic 21 . 23 be occupied with a checksum / hash. Then G could represent the starting value "seed" of the CRC, with SD = f (BE, G) = BEoCRC (seed = G, date = BE).

Another more complex encoding would be the use of G as a cryptographic key, either in symmetric encryption or in asymmetric encryption:
If z. For example, if the encryption method AES is used then SD = f (BE, G) = AES (key = G, date = BE).

On the receiver side is in the evaluation logic 100 . 101 the received SD 212 checked. Depending on the function used, f (BE, G) can be changed to either one in the receiver 10 known G 221 checked, ie a so-called "symmetric coding" or "asymmetric coding" by means of a to G 221 suitable G 'tested.

With symmetric coding, the receiver knows 10 G 221 and knows how SD = f (BE, G) is constructed. With this he can check if the received SD 212 the "correct" G 221 contains and BE 210 reconstruct.

For asymmetric coding, the receiver knows 10 one to G 221 matching G 'and knows how SD = f (BE, G) is constructed. So he can with g (SD, G ') on the correctness of SD 212 check and so BE 210 reconstruct, analogous to, for example, a PGP encryption. If SD 212 was checked correctly, then it is in the receiver 10 the reconstructed user input BE 210 as user input to be secured 210 to understand and perform an action, such as the validity of BE 210 to confirm.

Otherwise, an error or other meaningful reaction, for example only execution of such actions, the non-secure user input can be done on the receiver side.

When using a stop element 24 may in the described exemplary embodiment, a reset circuit 24-1 be necessary for the logic 21 . 23 reliable the secret G 221 again, forget the logic 21 . 23 or the secret G 221 in logic 21 . 23 has been deactivated, ie a change in the safety switching element 24-2 of the stop element 24 from safety switching element = 1 to safety switching element = 0 takes place. The task of the reset circuit 24-1 consists in this case, from a corresponding edge change a reset pulse for the logic 21 to create. In the steady state, ie safety switching element = 1, the reset pulse has expired, that is the logic 21 . 23 is not in reset, but ready for operation. When switching from safety-switching element = 1 to safety-switching element = 0, nothing changes. If then the safety switching element = 0 returns to safety switching element = 1, there is a corresponding one Edge change on and the reset circuit 24-1 generates the reset pulse and the logic 21 . 23 goes into the reset. Once the reset pulse has expired, the steady state is reached again. The reset circuit 24-1 should therefore be construed that logic 21 . 23 the previously explicitly or at least theoretically - also in case of error - known secret G 221 with sufficient probability reliably forgets as soon as the secret G 221 has been deactivated, ie safety switching element = 0 on safety switching element = 1.

The reset of the logic 21 . 23 For example, via an existing reset input in the logic 21 . 23 if a so triggered reset the internal memory of the logic 21 . 23 the G 221 contained with sufficient probability reliably delete / reset.

The reset of the logic 21 . 23 Alternatively, for example, via a, possibly even temporary, removal of the operating voltage from the logic 21 . 23 done if the logic 21 . 23 equipped with a volatile memory, which G 221 can contain.

5 shows a schematic representation of a proposed system for a vehicle for automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention.

In this case, the exemplary embodiment of the invention corresponds to 5 largely to that exemplary embodiment of the invention 4 , However, in this exemplary embodiment of the invention, the logic is not used 21 . 23 the secret G 221 to get out of G 221 and BE 210 an authenticated request information SD to be sent 212 (SD = f (BE, G).) Instead, the self-logic turns off 22 a date H in addition to the request information 211 SD of logic 21 . 23 ready to ship when the SichLogik 22 by means of the safety switching element 24-2 has been activated. In the simplest case, H = G and SD = BE.

Alternatively, one or both of the date values H and SD may be encoded, for example H = f1 (G) and SD = f2 (BE). H, respectively SD may also contain further information such as, for example, an identification of the transmitter "transmitter ID" or checksums such as CRC or sequence counter and the like. In the 4 shown reset circuit 24-1 is in the circuit in 5 no longer necessarily necessary, given the logic 21 . 23 here the secret G 221 never "knows", she must G 221 also not reliably "forgotten", but can be added optionally. In 5 is therefore the reset circuit 24-1 shown in dashed lines.

In this case, the mobile requesting device forms 2 an authenticated request information 212 SDH without the logic 21 . 23 the secret G 221 to announce. So SDH = f (SD, H) is sent. In this case, H and SD can be sent in a time-correlated manner, for example SDH = SDoH or SDH = HoSD. Alternatively, it is also conceivable that H is sent periodically and independently of SD. For example, only the logic could 21 . 23 the request information SD 211 and then the security logic 22 the H 211 to ship. On the receiver side, SDH is again checked for correctness and, if successful, action is taken. The procedure is analogous to that in 4 described.

Also in this circuit, a reliable deactivation of the SichLogik 22 when so when changing the safety switch element 24-2 of the stop element 24 from safety switch element = 0 to safety switch element = 1, analogous to that in 4 described. When the logic is off 22 No H can be generated and thus only the request information SD 211 and no authenticated request information SDH 212 to be shipped.

6 shows a schematic representation of a proposed system for a vehicle for automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention.

In this case, the exemplary embodiment of the invention corresponds to 6 largely to that exemplary embodiment of the invention 5 ,

In principle, the processes are similar to those in 5 described. In addition, the SichLogik refers 22 in calculating the date H, both the secret G and the request information SD coming from the logic 211 and then provide H for dispatch when the SichLogik 22 by means of the safety switching element 24-2 has been activated. Thus, H = f3 (G, SD). For example, f3 could be a checksum or an encryption function analogous to those in the three examples of 4 described. Sending and checking / evaluating on the receiver side are analogous to those in 4 described.

Also in this circuit variant can optionally be used a reset circuit - dashed circumference in 6 , In this circuit, a reliable deactivation of the logic 21 . 23 respectively of the secret G 221 in logic 21 . 23 also when changing from safety switch element = 0 to safety switch element = 1, analogous to that in 4 described. When the logic is off 22 no H can be generated as H = f1 (G) and thus only the request information SD 211 and no authenticated request information SDH 212 to be shipped.

7 shows a schematic representation of a proposed system for a vehicle for automated control of at least one safety-relevant function of a vehicle according to another exemplary embodiment of the invention.

In this case, the exemplary embodiment of the invention corresponds to 7 largely to that exemplary embodiment of the invention 5 , The main difference is that the logic 21 . 23 by means of the safety switching element 24-2 not completely activated / deactivated. Instead, in the case of a user input to be protected, that is, when the safety switching element 24-2 is one, the secret G 221 within Sich logic 22 be released. If the secret G 221 is released, then from SD an authenticated request information W 212 calculate such that W = f (SD, G). Without shared secret G 221 knows SichLogic G 211 not, so only a W 221 can be calculated to W = f (SD). W 212 is then sent and evaluated on the receiver side, analogous to in 5 described case.

In this variant, it is important that analogous to in 4 a reset when switching from safety switch element = 0 to safety switch element = 1 is triggered. However, this reset should be to an independent, from the safety switching element 24-2 activated part of SichLogik 22 walk.

The safety of the approaches described above can optionally be further increased by the following approaches:
The design of the safety switching element 24-2 can be done as a dead man's circuit. Thus, it can be ensured that in the case of a faulty operation, such as, for example, dropping the remote control 2 or a "slip" the system switches to a safe state S. This should be the safety switching element 24-2 of the stop element 24 be designed so that the operator must keep active during the entire control process of a user input to be protected safety switching element = 0. This can be given, for example, when safety switching element 24-2 a button - and no switch - is.

The safety switching element 24-2 may for example consist of several individual switching / tactile elements that need to be operated together. Also, the safety switching element 24-2 For example, consist of several individual switching / Tast elements that need to be operated in a sequence.

In addition to or in combination with the safety switching element 24-2 can also be in the user input BE 210 a distinction can be made between safety-relevant and non-safety-relevant inputs. For example, a combination of different keys / inputs in BE 210 be necessary to generate safety-relevant inputs. Also, for example, a sequence of different keys / inputs in BE 210 be necessary to generate safety-relevant inputs.

Advantages of the exemplary embodiment of the invention according to safety specifications shown in the figures are:
Regarding the function: The proposed invention allows the switching on and off of safety-relevant functionalities by requesting device 2 ,

Regarding the cost / effort: It does not inherit the entire transmitter-side extent the safety requirements. Instead, only the safety circuit, for example consisting of a safety switching element, possibly a reset circuit and a safety logic to safety requirements to develop / hedge. Thus, the effort for a development / protection, for example, defined by safety standards such as IEC 61508 or ISO 26262 to be reduced.

On the other hand, the conventional development / safeguarding according to safety requirements is usually associated with additional expenses, for example with regard to development effort, documentation, technical safety mechanisms such as diagnoses and the like, and is thus associated with additional costs.

Since, according to the invention, not the entire transmitter-side circumference but only the safety circuit is to be developed / safeguarded according to safety specifications, the approach proposed here leads to a cost reduction.

Regarding safety: At the same time, the safety of the system tends to be increased because the safety-relevant volumes are less complex.

Regarding the robustness / customer effect: In addition, the robustness of the functions increases, independently of the safety, as it also prevents such false activations which, if necessary, would not lead to any real danger but nevertheless represent unwanted behavior from the point of view of the customer / operator.

LIST OF REFERENCE NUMBERS

1

vehicle

10

outfeed

11

Safety-relevant function

100

receiver module

101

control module

1010

Safety-relevant module

2

mobile request device

21

requester

210

Safety-relevant requirement

211

request information

212

authenticated request information

22

authentication element

220

User activation of the authentication element

221

authentication information

23

transmitter module

24

stop element

24-1

Reset circuit

24-2

Safety switch element

241

stop information

V

validate

e

Result of validation V

S

safe condition

F

release

R

decline

X

To run

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been 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.

Cited non-patent literature

• IEC 61508 [0007]
• ISO 26262 [0007]
• IEC 61508 [0031]
• ISO 26262 [0031]
• IEC 61508 [0045]
• ISO 26262 [0045]
• IEC 61508 [0081]
• ISO 26262 [0081]
• ISO 26262 [0105]
• IEC 61508 [0140]
• ISO 26262 [0140]

Claims (12)

System for a vehicle ( 1 ), in particular a land vehicle, comprising - a mobile request device ( 2 ), and - an export device ( 10 ); wherein the mobile requesting device ( 2 ): - a request element ( 21 ), - an authentication element ( 22 ), and - a transmission module ( 23 ); the delivery device ( 10 ): - a receiving module ( 100 ), and - a control module ( 101 ), and wherein the delivery device ( 10 ) in the vehicle ( 1 ), the request element ( 21 ) is set up to respond to a safety-related requirement ( 210 ) of a user a corresponding request information ( 211 ) to the transmission module ( 23 ), the authentication element ( 22 ) is set up to provide authentication information ( 221 ) to the transmission module ( 23 ), the transmission module ( 23 ) is set up to provide a request information ( 211 ) by the request element ( 21 ) both the request information ( 211 ) as well as the provided authentication information ( 221 ) as an authenticated request information ( 212 ) to the delivery device ( 10 ), the receiving module ( 100 ) is set up to - the authenticated request information ( 212 ), - which in the authenticated request information ( 212 ) containing authentication information ( 221 ) (V), and - in the case of validity of the authentication information ( 221 ) in the authenticated request information ( 212 ) contain request information ( 211 ) to the control module ( 101 ) forward; and the control module ( 101 ) is set up to receive the request information ( 211 ) automatically. System according to claim 1, wherein the control module ( 101 ) a safety-relevant module ( 1010 ), and wherein the automated execution of the request information ( 211 ) by the control module ( 101 ) that based on the request information ( 211 ) the safety-relevant module ( 1010 ), at least one safety-relevant function ( 11 ) of the vehicle ( 1 ) to receive the request information ( 211 ) and the control over the adopted safety-relevant function ( 11 ) of the vehicle ( 1 ) to the safety-relevant module ( 1010 ) passes over. System according to claim 1 or 2, wherein the safety-relevant function ( 11 ) is defined as a function according to at least one safety standard from the selection of the safety standards IEC 61508, ISO 26262, a safety standard which is more stringent than these two, a safety standard which further develops at least one of the aforementioned standards and one Safety standard that corresponds to one of the aforementioned safety standards. System according to claim 3, wherein the request information ( 211 ), the authentication information ( 221 ) and the authenticated request information ( 212 ) each have a complexity that is sufficiently high that they are not randomly generated with a specified probability and are protected against corruption, the specified probability being derived from the safety-relevant function ( 11 ) and the protection against corruption can preferably be carried out by means of a checksum method, a CRC method, a signature method, an encryption method or a combination of at least two of the aforementioned methods. A system according to any one of the preceding claims, wherein the authentication information ( 221 ) is information that allows a conclusion as to whether the received request information ( 211 ) is valid. System according to any one of claims 2 to 5, wherein the safety-relevant requirement ( 210 ) a parking request relating to a forward parking process of the vehicle ( 1 ) or a Ausparkanforderung regarding a backward Ausparkvorganges the vehicle ( 1 ), and the adopted safety-relevant function ( 11 ) of the vehicle ( 1 ) - in the case of a parking request, a forward autonomous driving of the vehicle ( 1 ), and - in the case of a parking request, a reverse autonomous driving of the vehicle ( 1 ), wherein the autonomous driving steering movements of the vehicle ( 1 ). Mobile request device ( 2 ) for a system according to claim 1, wherein the mobile requesting device ( 2 ) is a remote control, in particular a radio remote control, preferably a vehicle key or a mobile communication device and comprising: - a request element ( 21 ), - an authentication element ( 22 ), and - a transmission module ( 23 ); and where - the requirement element ( 21 ) is set up to respond to a safety-related requirement ( 210 ) of a user request information ( 211 ) to the transmission module ( 23 ), - the authentication element ( 22 ) is set up to provide authentication information ( 221 ), and - the transmission module ( 23 ) is set up to provide a request information ( 211 ) by the request element ( 21 ) both the request information ( 211 ) as well as the provided authentication information ( 221 ) as an authenticated request information ( 212 ) to the delivery device ( 10 ) to send. Mobile request device ( 2 ) according to claim 7, wherein the authentication element ( 22 ) activated by the user ( 220 ), so that the authentication element ( 22 ) a valid authentication information ( 221 ) as authentication information to be sent ( 221 ). Mobile request device ( 2 ) according to claim 7 or 8, comprising a stop element ( 24 ), wherein the stop element ( 24 ) is set up to receive stop information at a request from the user ( 241 ) as requirement information ( 211 ) to the transmission module ( 23 ). Implementing device ( 10 ) for a system according to claim 1, wherein the delivery device ( 10 ): - a receiving module ( 100 ), and - a control module ( 101 ); the delivery device ( 10 ) is adjusted in a vehicle ( 1 ), the receiving module ( 100 ) is set up to - an authenticated request information ( 212 ), - one in the authenticated request information ( 212 ) containing authentication information ( 221 ) and, in the case of validity of the authentication information ( 221 ) one in the authenticated request information ( 212 ) contain request information ( 211 ) to the control module ( 101 ) forward; and the control module ( 101 ) is set up to receive the request information ( 211 ) automatically. Method for the automated control of at least one safety-relevant function ( 11 ) of a vehicle ( 1 ) for a system according to claim 1, comprising: - receiving an authenticated request information ( 212 ), - validating (V) one in the authenticated request information ( 212 ) contained authentication information ( 221 ), - forwarding in the authenticated request information ( 212 ) contains requirement information ( 211 ) and the result (E) of validating the authentication information ( 221 ) to a control module ( 101 ); the control module ( 101 ): - if the result (E) of validating (V) the authentication information ( 221 ) is negative and already has a safety-relevant function ( 11 ) of the vehicle ( 1 ): - transfer of the adopted safety-relevant function ( 11 ) into a safe state (S), and - releasing (F) the adopted safety-relevant function ( 11 ), - reject (R) the request information ( 211 ); If the result (E) of the validation (V) of the authentication information ( 221 ) is negative and no safety-relevant function ( 11 ) of the vehicle ( 1 ): - Rejecting (R) the request information ( 211 ); If the result (E) of the validation (V) of the authentication information ( 221 ) is positive: - if already a safety-relevant function ( 11 ) of the vehicle ( 1 ): - transfer of the adopted safety-relevant function ( 11 ) into a safe state (S), and - releasing (F) the adopted safety-relevant function ( 11 ); regardless of whether a safety-relevant function ( 11 ) of the vehicle ( 1 ): - determining on the basis of the request information ( 211 ), which safety-relevant function ( 11 ) of the vehicle ( 1 ), - transfer of the safety-relevant function to be transferred ( 11 ) into a safe state (S), - if the safety-relevant function ( 11 ) can not be converted into a secure state (S): - rejecting (R) the execution of the request information ( 211 ); - if the safety-relevant function ( 11 ) is transferred to a safe state (S): - acceptance of the safety-relevant function ( 11 ), and - executing (X) the request information ( 211 ). The method of claim 11, further comprising: - if the request information ( 211 ) a stop information ( 241 ) and is already a safety-relevant function ( 11 ) of the vehicle ( 1 ): - transfer of the adopted safety-relevant function ( 11 ) to a secure state (S) regardless of the result of validating the authentication information (S) 221 ), and - releasing (F) the adopted safety-relevant function ( 11 ).

Images