Method and apparatus for automating driving functions

Abstract

Method (10) for automating a driving function, characterized by the following features: triggering (15), under activation conditions (12) modeled by triggers (11), of an activation (13) of a process (14) controlling the driving function, and temporal control of the process (14) by an activation manager (16) during control of the driving function.

Description

TECHNICAL FIELD

[0001] The invention relates to a method for automating driving functions. The invention also relates to a corresponding device, a corresponding computer program and a corresponding storage medium. BACKGROUND

[0002] The term "highly automated driving" generally refers to a development stage between assisted driving, in which the driver is supported in the driving task by numerous, usually separate, driver assistance systems, and autonomous driving, in which the vehicle drives completely automatically and without intervention by the driver. It can be said that in the case of highly automated driving, the vehicle has its own intelligence, which can plan ahead and can take over the driving task at least in most situations. Driver and control device (electronic control units, ECUs) together guide the vehicle, wherein the human driver can at any time determine the extent of the driver's intervention in the driving behavior of the vehicle.

[0003] WO2018146000A1 discloses a control device for a motor vehicle, which is designed to operate a plurality of applications and middleware and comprises a shared memory which can be used jointly by the applications and middleware. The middleware is designed to develop inter-process communication between the applications via the shared memory.

[0004] DE102018207172A1 describes a method for simulating cyber-physical systems (CPS) in real operating conditions, in which measurement data and internal states of software components of the system in the operating conditions are stored and used to parameterize a simulator. SUMMARY

[0005] The invention provides a method for automating driving functions, a corresponding device, a corresponding computer program and a corresponding storage medium according to the independent claims.

[0006] The approach according to the invention is based here on the knowledge that numerous driver assistance systems for highly automated driving are currently in a formative phase. It can be expected that the complexity of the corresponding software is several orders of magnitude higher than in conventional automotive applications.

[0007] The proposed solution is also based on the insight that systems for highly automated driving are technically complex. The same applies to future robotic systems. The robotic systems require high computing power and large memories and the requirements for safety are significantly increased. The functional safety requirements additionally increase the system complexity.

[0008] Finally, the following approach takes into account the fact that current systems in the automotive environment are usually designed as directly communicating applications or components. As soon as data is available, it is immediately provided to other applications. Here, the exact temporal relationship between the individual applications cannot usually be precisely predetermined for technical reasons, for example because the number of independent computing cores is far behind the number of applications executable on the computing cores. Thus, it is sometimes difficult to determine the exact sending moment of specific data. The lifetime of data received by a particular application is therefore unpredictable and depends to a large extent on the runtime conditions.

[0009] The approach described in DE 102018207172 A1 makes this situation easier, because it is possible to explicitly determine which application receives which data given the input data. Thereby, consistency of data can be ensured for any process structure.

[0010] In order to post-mortem simulate and simplify the runtime behavior, it has proven useful to group multiple tasks into a system based on the method known per se. In the following, a complex of individual tasks based on a common activation scheme is referred to as an activation table.

[0011] The dynamic concept of such an activation table and its tasks, here specifically the activation, is usually based on periodicity and possibly on triggers of individual data. Both are generally manually configured or implemented.

[0012] In this context, one advantage of the solution according to the invention is that an abstract and general concept for modeling and defining complex activation conditions is created.

[0013] The basic idea explained in the independent claim can be advantageously extended and improved by the measures listed in the dependent claims. Thereby, a uniform modeling language for activation conditions can be set up. In this way, the activation conditions can be compared and, in the case of partial agreement, summarized, for example in activation tables, tasks or other activity threads. The complexity of this modeling is limited, for example compared to manually created source code. This reduces the risk of errors and makes it possible to perform automatic checks.

[0014] The actual program code for implementing the activation condition can be derived from its abstract definition. Thereby, the functional safety of the generated program code can be guaranteed by a well-defined structure, although the modeled activation condition finds its origin outside the middleware development. Thereby, a flexible allocation of such activation conditions is also guaranteed, which can be necessary, for example, in the context of the so-called lockstep concept. Thus, for example, a similar table implementation can be generated for a microcontroller if the microcontroller does not allow dynamic loading of program code.

[0015] Finally, the activation conditions modeled according to the application can be automatically taken over into a timing simulation, for example, supported by the software products "Timing Architects Tool Suite" or "chronSIM". This possibility supports the single source principle and reduces the development effort. BRIEF DESCRIPTION OF DRAWINGS

[0016] Embodiments of the application are shown in the drawings and are explained in detail in the following description.

[0017] Figure 1 A data flow diagram of the method according to the first embodiment is shown.

[0018] Figure 2 A control device according to the second embodiment is shown schematically. DETAILED DESCRIPTION

[0019] Figure 1 The basic idea of the method 10 according to the application based on a vehicle technology operating system is shown. For the activation 13 of the process 14, on the one hand, the operating system provides a periodic 19 trigger or stimulus 11, as is known from the prior art. On the other hand, the activation 13 can be made on the basis of predetermined events 17, 18, as described below.

[0020] As input variables of the activation condition 12, preferably middleware-centered stimuli from the IPC 18 are considered. For example, individual sample values transmitted via the middleware can be conceivable. In principle, any type of event-based stimulus 11 detected by the model can be considered.

[0021] Preferably, the activation 13 is also set if the event does not occur within a certain time period, for example 100 ms. In this case, information about the current timeout can be passed on to the process 14 to be activated.

[0022] For event-based stimuli 17, 18, a simple modeling language is defined, which according to the application is based on Boolean functions. According to the application, the Boolean functions are expressed here in disjunctive normal form (DNF), in particular as disjunction of product terms. According to a preferred embodiment, the Boolean expressions are further restricted, for example by excluding negation (NOT) or by using exclusive OR (XOR).

[0023] Preferably, a point notation is used in order to specify the IPC stimuli 18 more precisely. In the following, "eventA" denotes such a stimulus 19. The modeling language defines the following Boolean functions:

[0024] • eventA.any_sample: provides 1 if there is a buffered sample value available or a new sample value has been received since the last activation 13,

[0025] • eventA.new_sample: provides 1 if a new sample value has been received since the last activation 13,

[0026] • eventA.any_newest_sample: provides the last stored available sample value, i.e. the newest sample value received since the last activation 13,

[0027] • eventA.new_newest_sample: provides the newest sample value among the new sample values received since the last activation 13.

[0028] Preferably, this notation represents both a single sample value and a set of sample values, so that, for example, eventA.any_sample can return a set of sample values. In contrast, eventA.new_newest_sample always provides a unique, i.e. the newest, sample value.

[0029] The IPC stimuli 18 specified in this point notation are then used as arguments of predicates, which map the arguments to a logical value. Preferably, the IPC stimuli 18 can be specified here on the basis of their sequence number or time stamp, in particular if the IPC stimuli are known to and transmitted by the middleware.

[0030] Preferably, in addition to the predicates for determining whether the sequence numbers are equal (for example: "seq_eq (eventA.any_sample, eventB.any_sample)") (optionally with a specification of an offset), predicates for comparing the sequence numbers and the time stamps with a predetermined interval are also provided. For the time stamps, such a predicate can correspond to the following form:

[0031] tstamp_is_inside_interval (eventA.new_sample, eventB.any_sample, tearly, tlate).

[0032] As these examples have shown, it is possible to consider two or more-place predicates for the described modeling language without departing from the scope of the invention.

[0033] As Figure 2 The method 10 can be implemented, for example, in software or hardware or in a mixture of software and hardware, for example in the control device 20, as shown in the schematic diagram in Fig. 1.

Claims

1. A method for automating driving functions (10). It is characterized by the following features: Under the activation condition (12) modeled by trigger (11), the activation (13) of the process (14) controlling the driving function is triggered (15), and During the control of the driving function, the process (14) is controlled in time by the activation manager (16). The triggering (15) is performed through inter-process communication (18). The inter-process communication (18) mentioned above is performed via a middleware interface, and The activation conditions are modeled using a predetermined modeling language. The state of the interface is expressed as a Boolean variable in the modeling language, and The modeling language includes Boolean functions for the variables and comparison predicates for timestamps and sequence numbers.

2. The method (10) according to claim 1. It is characterized by the following features: The function is expressed in disjunctive paradigm in the modeling language.

3. The method (10) according to any one of claims 1 to 2. It is characterized by the following features: During the activation (13), the associated trigger (11) is transmitted to the process (14).

4. A computer program product designed to perform the method (10) according to any one of claims 1 to 3.

5. A machine-readable storage medium having a computer program product according to claim 4 stored thereon.

6. An apparatus (20) designed to perform the method (10) according to any one of claims 1 to 3.

Images