METHOD AND DEVICE FOR CONTROLLING A DRIVING FUNCTION

Abstract

A method for controlling a driving function. In the method, input data relevant for the driving function are conveyed to a cluster, output data are respectively generated by redundant processing of the input data on at least a first processing unit and a second processing unit in the cluster, the respective output data are supplemented by control fields by each processing unit, the output data of the processing units are conveyed to a comparison and a result of the comparison is ascertained, and depending on the result, the output data are utilized on a case-by-case basis together with the respective control fields for the driving function if the output data and control fields bear the comparison, or are marked as erroneous if the output data or control fields deviate.

Claims

1. A method for controlling a driving function, comprising the following steps: conveying input data relevant for the driving function are conveyed to a cluster; generating respective output data by redundant processing of the input data on at least a first processing unit and a second processing unit in the cluster; supplementing, by each of the first and second processing units, the respective output data by control fields. conveying the output data of the first and second processing units to a comparison and a result of the comparison is ascertained; and depending on the result, the output data are utilized on a case-by-case basis together with the respective control fields for the driving function when the output data and control fields bear the comparison, or are marked as erroneous when the output data or the control fields deviate.

2. The method as recited in claim 1, wherein: the input data are also provided with control fields; and based on the input data and the control fields being inconsistent, the input data are discarded prior to the processing.

3. The method as recited in claim 1, wherein: upon request, the input data are distributed by a control program to multiple servers of the cluster; each of the first and second processing units is operated on one of the servers; and the result or a failure of the comparison is reported back to the control program.

4. The method as recited in claim 3, wherein: the first and second processing units are application containers; processing of the input data, which are security-relevant for the driving function, and the comparison of the output data take place in protected containers from among the application containers; and the output data, which are not security-relevant for the driving function, are immediately forwarded.

5. The method as recited in claim 3, wherein: the cluster is a Kubernetes cluster; the servers are worker nodes in the cluster including pods replicated in pairs; the first processing unit is a first pod from among the pods, which is reachable via a first service of the cluster; the second processing unit is a second pod from among the pods, which is reachable via a second service of the cluster; the comparison takes place on a third pod from among the pods, which is reachable via a third service (73) of the cluster; and the services are synchronized by one shared input point on one of the worker nodes.

6. The method as recited in claim 5, wherein: prior to the processing on the first pod and second pod, the input data from the input point are provided with a matching identifier; and the output data presented first to the third pod for the comparison are stored in a cache until the output data to be compared are assigned to one another on the basis of the identifier.

7. The method as recited in claim 6, wherein: the buffering of the output data presented first for the comparison is confirmed by the third pod; after the comparison, the cache is released by the third pod; and the request remains pending until the result is reported back by the third pod.

8. A non-transitory machine-readable memory medium on which is stored a computer program for controlling a driving function, the computer program, when executed by a computer, causing the computer to perform the following steps: conveying input data relevant for the driving function are conveyed to a cluster; generating respective output data by redundant processing of the input data on at least a first processing unit and a second processing unit in the cluster; supplementing, by each of the first and second processing units, the respective output data by control fields. conveying the output data of the first and second processing units to a comparison and a result of the comparison is ascertained; and depending on the result, the output data are utilized on a case-by-case basis together with the respective control fields for the driving function when the output data and control fields bear the comparison, or are marked as erroneous when the output data or the control fields deviate.

9. A device configured to control a driving function, the device configured to: convey input data relevant for the driving function are conveyed to a cluster; generate respective output data by redundant processing of the input data on at least a first processing unit and a second processing unit in the cluster; supplement, by each of the first and second processing units, the respective output data by control fields. convey the output data of the first and second processing units to a comparison and a result of the comparison is ascertained; and depend on the result, the output data are utilized on a case-by-case basis together with the respective control fields for the driving function when the output data and control fields bear the comparison, or are marked as erroneous when the output data or the control fields deviate.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Exemplary embodiments of the present invention are represented in the drawings and are explained in greater detail in the following description.

[0016] FIG. 1 shows the basic configuration of the lockstep, in accordance with an example embodiment of the present invention.

[0017] FIG. 2 shows three servers including input data stream and output data stream, in accordance with an example embodiment of the present invention.

[0018] FIG. 3 shows a multi-step lockstep principle for data on different automotive safety integrity levels (ASIL), in accordance with an example embodiment of the present invention.

[0019] FIG. 4 shows the implementation of the lockstep principle in a Kubernetes cluster, in accordance with an example embodiment of the present invention.

[0020] FIG. 5 shows the UML sequence diagram of a logical lockstep function, in accordance with an example embodiment of the present invention.

[0021] FIG. 6 shows the data exchange including E2E protection between replicas, in accordance with an example embodiment of the present invention.

[0022] FIG. 7 shows an example of a highly available lockstep application in independent, particularly protected containers, in accordance with an example embodiment of the present invention.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0023] FIG. 1 illustrates a cluster including functions according to the present invention. The basic functions are carried out with homogeneous redundancy on two different servers 31, 32, the results of which are compared by an independent comparator 25 (also referred to in the following as “comparator”). In order to further increase the availability of the lockstep, the cluster may be supplemented by a third homogeneously redundant server 33 to form an error-tolerant control system having “2003 architecture” according to IEC 61508. If two results match in an architecture of this type, the matching information is forwarded.

[0024] A task scheduler 23 schedules the processing steps. If the results deviate from one another, these data could only be discarded according to a conventional method; often, both computing cores are switched off in this case by a so-called watchdog. The method according to the present invention, however, pursues the goal of marking the erroneous data as such and, thereby, maintaining the data stream. Moreover, the data to be compared are to be reduced to essential security information.

[0025] As FIG. 2 illustrates, the same input data 11 are conveyed to all three servers 31, 32, 33. In order to achieve the greatest possible independence, all external and server-internal data streams should be continuously protected. In a first processing step, it is to be ensured that input data 11 of all servers 31, 32, 33 are detected at the same point in time, so that the comparison is based on a uniform data status.

[0026] This synchronization of input data 11 is followed by the actual logic data processing before output data 15 are prepared for transmission. Conventionally, these three processing steps run in a clock-synchronized manner, which substantially extends the run time of a lockstep system as compared to a single core system.

[0027] Due to the E2E protection according to the present invention, the particular challenges of a distributed processing in the cloud are also taken into consideration, in that all relevant effects on the lockstep system result in an inconsistency between the payload and E2E control fields and, for example, may be detected within the scope of a cyclical redundancy check or any other type of security check. Provided output data 15 of servers 31, 32, 33 are identical, these may also be transferred to downstream computation units or vehicles. Even in the case of run time fluctuations or data loss within the scope of the communication, the first incoming packet may already be utilized for a safe driving function.

[0028] In principle, a separation of virtual processing units by container-based virtualization may also be achieved in the cloud as on a local server, for example, with the aid of dockers. Each application container is utilized in this case as an independent processing unit. Usually not all data and functions of a processing unit of this type are security-relevant; therefore, the amount of input data 11 to be processed may be reduced due to a limitation to security-relevant data.

[0029] FIG. 3 shows a server 31 including multiple such application containers 41, 42, 51, 52, output data 15 (FIG. 2) of which are compared in the lockstep. In the example, all data are processed by containers 41, 42, 51, 52 with homogeneous redundancy. All data relevant for the functional safety are conveyed to particularly protected containers 51, 52. The latter are additionally utilized as comparators 25 (FIG. 1) for the two regular application containers 41, 42. Security enclaves may be set up within particularly protected containers 51, 52, in order to also protect the data comparisons against hacker attacks in the best way possible. Non-security-relevant output data 15 (FIG. 2) of regular containers 41, 42, however, may be advantageously immediately forwarded and utilized for driving functions. Optionally, the data may be activated for the further processing for less critical functions—such as steps ASIL B or SIL 2—after the positive comparison in one of safety containers 51, 52.

[0030] FIG. 4 illustrates an implementation example of a Kubernetes cluster 26 made up of multiple so-called pods 61, 62, 63, each of which may include one or multiple application container(s). The two pods 61, 62, which accommodate containers 41, 42 functioning as processing units, and comparator 43 are each reachable via a separate service of cluster 26; these services 71, 72, 73 are synchronized by one shared input point 27 on a worker node 31 of cluster 26.

[0031] The behavior of cluster 26 follows the sequence according to FIG. 5. Prior to the processing, input data 11 from input point 27 are provided with a matching identifier, on the basis of which they may be assigned to one another 28 by comparator 63. In the meantime, output data 15 (FIG. 2) presented first to comparator 63 are stored 29 in a cache, which is preferably jointly utilized by multiple instances and may be released 35 again after the comparison. According to the guiding principle of a service-oriented architecture (SOA), the requests remain pending up until the respective result 24 is reported back.

[0032] The logical lockstep function yields the overall image from FIG. 6. Redundant replicas of pods 61, 62, 63 should run on different worker nodes 31, 32, 33, 34, so that the system function of the lockstep remains ensured in the event of failure of an individual node 31, 32, 33, 34. The Kubernetes load balancing may automatically compensate for such failures.

[0033] In addition to the porting of the lockstep principle into the cloud environment, the mechanisms of the error control represent an essential aspect of the method provided here. It is meaningful to allow the lockstep to operate in parallel to the intended function, so that the data stream may be activated for the further processing only after the successful checks.

[0034] Due to the E2E protection, the sources of possible errors are made perceptible. Errors due to external effects are already indicated by a violation of the E2E protection.

[0035] The dependencies of the individual functional elements in the Kubernetes cluster 26 are also indicated by violations of the E2E security. In particular, the paths from one computer outside the cluster to the specific Kubernetes cluster 26 are protected against all effects by the E2E architecture.

[0036] All input and output data of the lockstep are also identified by the violation of the E2E comparison. Therefore, in the case of small amounts of security data and real-time data to be processed quickly, these two lockstep steps (input data comparison and output data comparison) may be dispensed with. Due to the prompt comparison in the lockstep, according to the present invention, only errors of one processing unit, which result from errors at its set of commands, are to be taken into consideration. A logical function such as dividing, adding, or taking the logarithm may be quickly compared and the amount of data, which are actually to be compared in a clock-synchronized manner, may be significantly reduced. Alternatively, a coded processing according to IEC 61508 enters into consideration, as part of which only the codings are compared in the lockstep method and the data evaluated as correct are forwarded without delay.

[0037] FIG. 7 shows one possible variant of method 10. In particular, at the outputs, comparator 25 (FIG. 1) could also additionally compare the time stamps and, thereby, the point in time at which output data 15 were conveyed 17 thereto. At this point, in the case of a real-time system, a check could also be carried out to determine whether the data are conveyed 17 to comparator 25 (FIG. 1) in a timely manner. If the data and their control fields or signatures prove to be incorrect in the comparison, this delayed finding could nevertheless be forwarded to a further processing unit and provided 20 with a unique signature, which characterizes result 24 (FIG. 1) as delayed, but not incorrect with respect to content. This indication often results in degradations in relevant systems. In soft real-time applications, a result 24 (FIG. 1) of this type could also be tolerated.

[0038] Comparators 25 (FIG. 1) may also asynchronously check all features; in this way, for example, comparisons of data, signatures, and time stamps could be checked in a logically differently stepped manner, so that final result 24 (FIG. 1) is sent time-delayed on the highest security level only after all comparisons and checks have been carried out.

[0039] Example embodiments of the present invention are also described in the following numbered paragraphs.

Paragraph 1. A method (10) for controlling a driving function, characterized by the following features: [0040] input data (11) relevant for the driving function are conveyed (13) to a cluster (26), [0041] output data (15) are respectively generated by redundant processing (14) of the input data (11) on at least a first processing unit (41) and a second processing unit (42) in the cluster (26), [0042] the respective output data (15) are supplemented (16) by control fields by each processing unit (41, 42), [0043] the output data (15) of the processing units (41, 42) are conveyed (17) to a comparison and a result (24) of the comparison is ascertained (18), and [0044] depending on the result (24), the output data (15) are utilized (19) on a case-by-case basis together with the respective control fields for the driving function if the output data (15) and control fields bear the comparison, or are marked (20) as erroneous if the output data (15) or control fields deviate.
Paragraph 2. The method (10) as recited in Paragraph 1, characterized by the following features: [0045] the input data (11) are also provided with control fields, and [0046] if the input data (11) and the control fields are inconsistent, the input data (11) are discarded (12) prior to the processing (14).
Paragraph 3. The method (10) as recited in Paragraph 1 or 2, characterized by the following features: [0047] upon request (22), the input data (11) are distributed by a control program (23) to multiple servers (31, 32, 33) of the cluster (26), [0048] each processing unit (41, 42) is operated on one of the servers (31, 32, 33), and [0049] the result (24) or a failure of the comparison are reported back to the control program (23).
Paragraph 4. The method (10) as recited in Paragraph 3, characterized by the following features: [0050] the processing units (41, 42) are application containers (41, 42, 51, 52), [0051] the processing (14) of the input data (11), which are security-relevant for the driving function, and the comparison of the output data (15) take place in particularly protected containers (51, 52) from among the application containers (41, 42, 51, 52), and [0052] the output data (15), which are not security-relevant for the driving function, are immediately forwarded (21).
Paragraph 5. The method (10) as recited in Paragraph 3 or 4, characterized by the following features: [0053] the cluster (26) is a Kubernetes cluster (26), [0054] the servers (31, 32, 33) are worker nodes (31, 32, 33, 34) in the cluster (26) including pods (61, 62, 63) replicated in pairs, [0055] the first processing unit (41) is a first pod (61) from among the pods (61, 62, 63), which is reachable via a first service (71) of the cluster (26), [0056] the second processing unit (42) is a second pod (62) from among the pods (61, 62, 63), which is reachable via a second service (72) of the cluster (26), [0057] the comparison takes place on a third pod (63) from among the pods (61, 62, 63), which is reachable via a third service (73) of the cluster (26), and [0058] the services (71, 72, 73) are synchronized by one shared input point (27) on one of the worker nodes (31, 32, 33, 34).
Paragraph 6. The method (10) as recited in Paragraph 5, characterized by the following features: [0059] prior to the processing (14) on the first pod (61) and second pod (62), the input data (11) from the input point (27) are provided with a matching identifier (28), and [0060] the output data (15) presented first to the third pod (63) for the comparison are stored in a cache until the output data (15) to be compared are assigned (29) to one another on the basis of the identifier.
Paragraph 7. The method (10) as recited in Paragraph 6, characterized by the following features: [0061] the buffering of the output data (15) presented first for the comparison is confirmed (30) by the third pod (63), [0062] after the comparison, the cache is released (35) by the third pod, and [0063] the query (22) remains pending (36) until the result (24) is reported back by the third pod (63).
Paragraph 8. A computer program, which is configured for carrying out the method (10) as recited in one of Paragraphs 1 through 7.
Paragraph 9. A machine-readable memory medium, on which the computer program as recited in Paragraph 8 is stored.
Paragraph 10. A device (31, 32, 33, 34), which is configured for carrying out the method (10) as recited in one of Paragraphs 1 through 7.