Data processing network for data processing

Abstract

A data processing network (1) for the redundant and verified implementation of a plurality of successive data processing steps (2), each of which serves to generate output data (4) from input data (3), the output data (3) of a first data processing step (2) being, at least partially simultaneously, the input data (3) of a further data processing step (2), and for the implementation of each data processing step (2) at least one first data processing module (5) is provided, the data processing network (1) further comprising a comparator module (7), the first data processing module (5) being adapted to calculate the control parameters of the individual data processing steps (2). 1. A data processing network (1), comprising: a meter (8) designed to transmit a meter (8) to a comparator module (7), the comparator module (7) designed to provide synchronization control parameters (9) comprising control information relating to at least one data processing step (2) to be performed; the data processing network (1) comprising a recording module (29), in which a debug mode is activatable, the debug mode recording debug data (30), the debug data (30) comprising information relating to each execution of the data processing step (2) by the data processing network (1).

Description

[Background technology]

[0001] Systems for assisted or autonomous driving consist of many individual software units, which can usually be represented in terms of data flows as graphs. These software units (often called runnables, nodes, or data processing components) are characterized by the large amount of input data they process and the large amount of output data they generate.

[0002] In the above system, input data from sensors such as radar or video is processed as a graph from a data processing component, and the graph is visualized in a static view of the data flow.

[0003] The various software units typically form a complex data processing network, by which the sensor data are processed and actions are performed on the basis of the sensor data. Such actions may, for example, be control tasks in the framework of autonomous driving of a vehicle. Data processing in a data processing network typically comprises several successively constructed data processing steps or data processing tasks executed by data processing components.

[0004] As part of the functional safety requirements for driver assistance systems and (highly) automated driving (HAD), the probability of systematic and sporadic hardware errors must not exceed a predetermined frequency related to the risk and expected damage to the system function. Since newly developed driver assistance systems are typically used in parallel with one another in a large number of vehicles and the associated risk for the entire equipped vehicle fleet can be assessed accordingly, the tolerable probability of the occurrence of a hardware error is very low.

[0005] Compared to today's high-end processors, commonly available microcontrollers that meet these security levels have very limited computing power: their maximum clock speed is about 10% (300MHz vs. 3GHz), and they lack the internal optimizers that are standard in, for example, commercial microprocessors (μPs), which significantly impact their performance.

[0006] In this context, a major problem is the detection (debug) of errors in program code. Because the amount of data processed in such applications is so large, it is often very costly to reproduce specific undesired behaviors of such software for development purposes. Such software is run for testing, for example, in a vehicle performing test runs. In this process, a very large amount of data is captured, for example, by a camera sensor, and processed in a data processing network. With the usual approach, this data is no longer available in the same form in order to perform tests again later to reproduce the respective erroneous behavior. Summary of the Invention [Problem to be solved by the invention]

[0007] Based on the above, a novel approach to building a data processing network for an automobile is presented that addresses the limited computing power of commonly available microcontrollers for such a security level. [Means for solving the problem]

[0008] Here, a data processing network is shown for redundant and verified execution of a plurality of successive data processing steps, each of which serves to generate output data from input data, the output data of a first data processing step being, at least partially simultaneously, input data for a further data processing step, at least one first data processing module is provided for the execution of each data processing step, the data processing network further comprises a comparator module, the first data processing module is designed to send control parameters of the individual data processing steps to the comparator module, the comparator module is designed to provide synchronization control parameters, the synchronization control parameters comprising control information relating to at least one data processing step being executed, the data processing network comprises a recording module, a debug mode can be activated in the recording module, the debug mode records debug data, the debug data comprising information about each execution of the data processing steps by the data processing network.

[0009] It is particularly preferred if the data processing network comprises a second data processing module for at least one first data processing module, the second data processing module being designed to perform the same data processing steps as the assigned first data processing module and to transmit control parameters to the comparator module, and the synchronized control parameters being generated by at least one comparison of corresponding control parameters transmitted by the first and second data processing modules.

[0010] The data processing network described herein features a recording module that permanently records debug data containing information about each execution of a data processing step, based on which a replay of each data processing step can be achieved later in the data processing network and / or in a test environment.

[0011] In the described data processing network comprising the first data processing module and the second data processing module, software lockstep can be realized on the basis of hardware that does not inherently fulfill the corresponding requirements (e.g., ASIL-D compliance), which is particularly suitable for data processing networks that require high computing power for data processing, which typically requires very high-performance hardware.

[0012] The basic idea is that separate hardware (separate cores) are used for the first and second data processing modules, each with high computing power and both performing the same calculation. A comparator module compares the calculations, and only if the calculation results are identical is this calculation result used for further data processing in the data processing network. The identity is monitored by the data processing modules based on control parameters, and synchronization control parameters are used in the data processing network to control the control flow of the data processing.

[0013] The point at which the first data processing module and the second data processing module provide control parameters which are then forwarded to the comparator module is also commonly referred to as the synchronization point.

[0014] As mentioned above, the method described herein relates to so-called software lockstep, which can be distinguished from hardware lockstep, which requires significantly more complex hardware.

[0015] Hardware lockstep, not claimed herein, is generally implemented using hardware that executes twice each computational step of a software program running on the hardware. This means that the software program itself executes only once on the hardware. The operating system recognizes only one instance of each software program. The hardware executes each step of the software twice, below one operating system level.

[0016] In contrast, software lockstep as described herein means that the programs are executed in a dual manner, i.e., at the operating system level. In some cases, two independent operating systems (a first operating system on a first data processing module with a first hardware / core, and a second operating system on a second data processing module with a second hardware / core) can be run, each performing its own (and therefore dual) data processing steps.

[0017] Software lockstep can also run on one operating system, possibly with instructions at the operating system level to use different hardware (two different cores) for dual execution.

[0018] As soon as there are two instances that can be replicated / multiplied without changing the hardware, the dual execution becomes what is called software lockstep. Hardware lockstep always means that additional hardware (circuits, transistors, etc.) must also be required for the additional redundant execution, but the hardware is located below the operating system level, and the operating system cannot see them as separate pieces of hardware; from the operating system's perspective, they appear as one piece of hardware. That is, using hardware lockstep always requires at least twice as many transistors to achieve the same performance as without hardware lockstep.

[0019] With or using the described data processing network, a lockstep approach is possible even on controllers / processors not specially developed for this purpose.

[0020] However, in most cases, the first and second data processing modules are executed by the same software and use the same hardware (same cores) in terms of their specifications. As long as each data processing module or the underlying hardware functions correctly, the same input data will produce the same output data in both data processing modules.

[0021] When software lockstep is used for (near) real-time applications, many known architectures are based on a time slice grid, where the processing of a computational step must never exceed a certain frame. In this context, the so-called WCET (WCET = Worst Case Execution Time) is often considered. Here, which computational steps will be executed in what order within a time slice is determined in advance. Since the computational steps are known in advance, the two units used can execute them in parallel. In many cases, the amount of computation required to process input data and generate output data varies greatly. An example is the case of image analysis to find all visible traffic signs. The data processing steps to perform such an analysis require much longer time when, for example, 100 traffic signs are visible at the same time than when there are only two traffic signs in the field of view. In a typical software lockstep approach, time slices would have to be designed based on the WCET to ensure that there is at least enough time to execute the data processing steps for all possible relevant cases.

[0022] In comparison, data-driven systems are more flexible, but their execution order can depend on the results and duration of previous computations. The order of computation steps is no longer known in advance. In the case of SW lockstep, this characteristic means that possible branching points must also always be synchronization points. Here, when computation units are used in parallel, the result of a computation step must always be verified before the next step can be safely determined and executed.

[0023] Therefore, in a data-driven architecture, rather than computing in parallel, it may be more efficient to run computation units (in advance, without synchronization) and then re-compute and verify the results on other units (under the same execution order rules). Thus, in this case, there is a primary module that rules the computations on the secondary modules below.

[0024] Today's hardware lockstep-enabled microcontrollers do not meet the computational power requirements needed for highly automated driving, while current high-performance processors do not meet the required ASIL-D safety level.

[0025] Nevertheless, to obtain a computing system for highly automated driving, a method must be found to adequately secure fast but insecure processors. For this purpose, the use of software lockstep is proposed.

[0026] The simplest way to try this would be to implement software lockstep on a corresponding microprocessor, but this would not only (at least) halve its computational power, but would also introduce two serious problems: on the one hand, systematic errors in redundant calculations on the same hardware would not be eliminated, and on the other hand, the necessary comparators for comparing output data / calculation results would also be implemented on equally unreliable hardware, so the results would not be fully reliable.

[0027] To solve this problem, it is proposed to implement software lockstep based on at least two modules with hardware isolated from each other and one comparator unit (comparator module), which runs on additional ASIL-D compliant hardware.

[0028] Furthermore, the approach described above requires a maximum required computation time that takes into account the WCET, but because this maximum computation time is typically only needed in exceptional cases, most steps end up with a "leftover" time that accumulates across the system's processing chain, resulting in unacceptable latency and poor hardware utilization. Thus, the danger with parallel software lockstep with a predetermined execution order and use of the WCET is the inability to achieve or fall below the required maximum latency across the system.

[0029] Furthermore, significantly improved utilization could be achieved using a data-driven architecture, such as the one that could be constructed above with, for example, a primary module and a secondary module for recalculation, where each subsequent data processing step is performed ad-hoc, without the need to know the exact process in advance, thus providing a high degree of flexibility.

[0030] However, such architectures, especially in the automotive applications described herein, have drawbacks that are briefly explained below: The execution order is predetermined by the primary module. The dependent secondary modules recalculate "blindly," so to speak. Therefore, the execution order can only be checked based on invariants or general rules, if at all. This results in the same level of security for the control flow as for the individual hardware used. Such an architecture cannot achieve a high ASIL-D level. In other words, a recalculation by a secondary module can later determine that the primary module's calculation contained an error, but in this case it is already too late, since the result of the calculation was already needed beforehand.

[0031] The calculation comparison can always be performed only after the redundant calculation step and subsequent transmission of the result has been completed. This essentially doubles the time it takes to find a calculation error. This leads to an increased error delay time, and possibly even to unnecessary delays in the normal process.

[0032] That is, although the known approach of lockstepping with primary and secondary modules does indeed allow for more flexible and data-driven execution, it also suffers from the problem of increased latency.

[0033] The presented data processing network and the data processing method implemented therein achieve sufficient performance for highly autonomous driving. The presented data processing network realizes a hybrid time-driven and data-driven architecture, i.e., allows for flexible execution order in software lockstep compared to approaches that use a predetermined execution order.

[0034] For this purpose, a software lockstep approach, implemented in parallel but not based on time slices, is chosen, which is realized in at least two microprocessors as calculation units (a first data processing module and a second data processing module) and a control component running on additional trusted hardware (a comparator module). This control unit, which complies with the safety target standard, synchronizes the processing on these calculation units and compares their results.

[0035] Compared to lockstep of primary / secondary modules, redundant calculation steps are processed (almost) simultaneously and therefore no cascading occurs, which improves the delay behavior (see Figure 3). Instead of sending complete data packets to the comparator, in the data processing network described here it is also possible to transmit only the checksum of the data (packet) as a control parameter from the data processing module to the comparator module, which in some cases can significantly reduce the amount of communication.

[0036] These optimizations, along with the combined data-driven and time-driven operation, result in good and efficient utilization of the hardware. From the security architecture point of view, the structure of the described data processing network corresponds to a decomposition of security-critical tasks, which reduces the ASIL requirements for the individual computing units, so that the ASIL-D level of the overall system can already be achieved with currently existing high-performance processors.

[0037] In order to make the described data processing network applicable to the execution of software, the following assumptions are made: All data and all associated control events are mapped to a timeline, or an equivalent structure, such as an event queue. The timeline can also be called a "common logical timeline." Each computation step initiated by a control event is data deterministic, i.e., given the same starting state, the output data is always the same if the input data is the same.

[0038] It is particularly advantageous if the comparison of the control parameters comprises an identity check, and the synchronized control parameters presuppose identity of the control parameters from the first data processing module and the second data processing module.

[0039] It is also advantageous if the data processing network is designed to use synchronization control parameters provided by the comparator module to control further data processing of the output data by further data processing steps of the data processing network.

[0040] Furthermore, it is advantageous if the synchronization control parameter is a validity parameter which contains validity information regarding at least one data processing step to be performed. It is also advantageous if the data processing network comprises at least one sequence module, each of which is designed to reorder and synchronize control parameters from the data processing modules and / or data processing steps and then transfer them by reordering to the comparator module, so that the comparator module can determine the synchronized control parameters independently of the order in which the data processing modules have executed the data processing steps.

[0041] The sequence modules are used, inter alia, to determine the order in which data processing steps are completed in the individual data processing modules, in particular with the hardware available in each case. In this way, the availability of hardware for performing further data processing tasks can be determined. The sequence modules are assigned to the respective data processing modules and transmit control parameters to the comparator modules or to the (third) hardware component on which the comparator modules are operated.

[0042] Preferably, a synchronizer is additionally present, which synchronizes the control parameters of the two data processing modules (which correspond completely unless an error occurs) with each other and, if necessary, forms a control parameter tuple that is supplied to the comparator module. The synchronizer and the comparator module preferably together form a central unit that is run on a (third) hardware component. By means of the synchronizer, flexibility in the order of execution of the data processing steps is achieved. The hardware of each data processing module can also be used to execute further data processing steps (when this hardware has finished executing a data processing step).

[0043] Since the first and second data processing modules perform the same data processing steps, in a normal process each will generate the same control and data events as the other, but due to parallel processing in the units they may be generated in a different order.

[0044] Here, the central unit (consisting of a comparator module and a synchronizer) temporarily stores events (control parameters) until the appropriate events (corresponding control parameters) arrive from all data processing modules, then it can compare the relevant control parameters and, if they are equal, evaluate them or output a synchronized control parameter.

[0045] Preferably, a task distribution module is additionally present, which then plans and requests the start of each (next) data processing step on the respective hardware when synchronization control parameters by the hardware modules are present, thereby achieving particularly good utilization of the hardware.

[0046] The task distribution module preferably provides certain stimuli to the individual data processing modules to activate them. The use of a central unit or third hardware component and a comparator module does result in a slight increase in the latency between the execution of two data processing tasks. However, overall, this increase in latency is acceptable, especially when compared to a typical primary / secondary module architecture.

[0047] If the central unit or the synchronizer, sequence module, and comparator module cannot determine a unique sequence of the received control parameters / events, an error event may be determined, which, depending on the application, may result in a new recalculation or the termination of data processing in the data processing network.

[0048] The central unit detects the stimulus in a specific way. Whenever the comparator module determines the correct calculation result by comparing the control parameters and is able to calculate the synchronized control parameters, a stimulus is found, so to speak, which triggers further data processing, which requires the output data calculated by the respective first data processing module and the respective second data processing module as input data. To find a possible stimulus for executing a further calculation step, the central unit evaluates not only all received data events (control parameters) but also events indicating the end of the previous calculation step ("End" or "DistributeSamples"). Furthermore, time events can be generated as stimuli for time-driven execution.

[0049] The central unit manages, so to speak, the timeline (common logical timeline) mentioned above in addition to the data processing. This ensures that under normal circumstances, all computational units, whether data-driven or time-driven, will achieve the same resulting process, despite possible differences in local execution order.

[0050] It is particularly preferred if a recording module is connected to the comparator module and is designed to record the control parameters occurring in the comparator module. The comparator module and the control parameters arising therein (especially the synchronization control parameters, but possibly also the control parameters sent by the data processing module) form particularly good suggestions for the recording module for recording the debug data. Via these control parameters, the basic structure of the debug data to be recorded can already be generated. The control parameters form a kind of basic data framework for the debug data, into which further data can be imported for later execution (replay) of the respective data processing steps of the debug system.

[0051] In addition to the comparator module, preferably all data processing modules of the data processing network are also connected to the recording module. The comparator module itself usually does not receive the actual processed data, but only information about when and which data enters the module. Not data, just control parameters. Preferably, there is also a data connection between the data processing module and the recording module to record the data actually processed in the data processing module.

[0052] Preferably, the recording module is also designed to record the state of the at least one first data processing module and / or the at least one second data processing module upon activation of the debug mode.

[0053] This state includes, among other things, the internal memory state of the memory area allocated to the respective data processing module. This state may already contain a considerable amount of data that must be stored there. Since the data transmission volume of the data describing the state is very large, the storage of such a state may in some cases require a longer period of time. In this case, the storage of the state may still be taking place even though further data processing steps have already been completed. Preferably, the recording module is equipped with a suitable technology for this.

[0054] The state must typically be recorded by each data processing module, which is typically necessary to make the entire state of the data processing network available for debugging.

[0055] Preferably, the recording of the (internal) state of the data processing module is periodically repeated. It is certainly sufficient to record the state once at the start to start the operation of the debugging system. Nevertheless, it is also useful to record further states (so-called key frames) during operation (as long as sufficient bandwidth is available). Thus, the debugging system does not necessarily have to start from the beginning of the recording by the recording module, but can start for each key frame.

[0056] It is further preferred that the recording module is designed to record initial input data of each data processing step of the data processing network upon activation of the debug mode.

[0057] Preferably, the data processing network comprises a number of interconnected data processing steps of data processing of sensor data up to (final) output data of the data processing network. In this system, each data processing step or each data processing module has input data. Preferably, the recording module is configured to record the input data for each repeated data processing step at least once (upon activation of the debug module) as initial input data, so that these input data can be used to synchronize the starting state of the entire data processing network in the debug system.

[0058] It is further preferred if the recording module is designed such that a recording of the input data of each data processing step is made permanently while the debug mode is activated. When the available bandwidth for data recording allows, the input data of each individual data processing step is recorded in a particularly persistent manner. Particularly preferably, there is a dynamic mode which performs input data recording while the debug mode is active, whenever this is possible in terms of the available bandwidth without causing any adverse effects on the system as a whole.

[0059] It is further preferred if the data processing steps are assigned priority parameters and information relating to each execution of the data processing steps is recorded in response to these priority parameters. Depending on the bandwidth available for recording data, the priority threshold can be adapted until data is recorded in debug mode, where more data is written in debug mode when more bandwidth is available than when the available bandwidth is limited and only the bare minimum of data required to synthesize the state of the data processing network within the debug system is recorded in debug mode.

[0060] It is particularly preferred that the data processing network is capable of activating a braking mode in the debug mode, which can ensure that information about each execution of a data processing step is fully recorded.

[0061] Typically, when a data processing network is in operation, there is already a shortage of available computing power and bandwidth to perform the data processing steps required for data processing. For this reason, the operation of the recording module and the execution of the debug mode, including the recording of debug data, are important processes that may require the provision of capacity for recording data. This can be achieved by the described braking mode, in which the operation of the data processing network is adjusted at least to the extent that complete recording of the required information is possible in the debug mode.

[0062] Particularly preferably, in braking mode it is ensured that all input data (especially sensor data) at the first level are completely recorded in the system, and that data generated by modules inside the system are only recorded according to priority and available bandwidth, so that the system is only braked if the system limits do not allow the input data (especially sensor data, and also data at the start of the system, such as the state and input data of each module at the start of the system) to be completely recorded. Also, input data of modules that may be synthesizable in the debug system, and states that occur during recording (keyframes), are preferably recorded only if this is possible without slowing down the data processing network below certain limits.

[0063] Advantageously, the first data processing module is realized by a first hardware component and the second data processing module is realized by a second hardware component, the first hardware component and the second hardware component being physically separated from each other.

[0064] It is also advantageous if at least one of the data processing modules comprises hardware components that are not ASIL-D compliant. It is particularly advantageous if both hardware components of the data processing module are not ASIL-D compliant.

[0065] It is also advantageous if the comparator module is realized by a third hardware component that is physically separated from the first and second hardware components.

[0066] In this context, it is advantageous if the third hardware component is ASIL-D compliant. It is also advantageous if the comparator module comprises a data memory in which the determined control parameters are stored together with time information, thus obtaining a logical timeline representing the order of processing of data processing steps by the data processing modules of the data processing network, and if the recording module is designed to record this logical timeline together with a flowchart of the performed data processing steps in debug mode.

[0067] The recording on this logical timeline is aided by a data framework formed, inter alia, by control parameters, which preferably also contain time information of the individual executions (start and end times of the execution of the individual data processing steps by the data processing module), which can be used to preferably map all data processing steps recorded by the recording module, including the data processed in each case, onto the logical timeline.

[0068] In this connection, it is also advantageous if the hardware components of the data processing module are significantly more powerful than the hardware components of the comparator module. The possible performance difference between the third hardware component of the comparator module and the (first and second) hardware components of the data processing module depends on the respective application of the data processing network. Typically, for example, the processor clock of the first and second hardware components is at least five times, and possibly even ten times, faster than the processor clock of the third hardware component.

[0069] To reduce the load on the communication paths between the data processing modules and the central unit (the comparator module, and possibly the sequence module and task distribution module), control parameters can be calculated for large data volumes as output data, and possibly their checksums (CRCs), and only these, along with a unique packet identifier (also known as a metasample), are sent to the comparator module as control parameters. The actual flow of the output data of a data processing step as input data to the next data processing step can occur independently or in parallel on the first and second hardware components (and possibly also on further hardware components), and possibly there is also a data transmission interface between the different hardware components that is also independent of the central unit or comparator module. In this case, the central unit or comparator module does not check the original data, but rather, for example, checks their checksums, which results in a bit-by-bit comparison of the original content. Note that the first and second hardware components must temporarily buffer the original data packets until they can be verified by the comparators and delivered.

[0070] Since the calculation of the checksum proposed here as a control parameter for transfer to the comparator module also consumes significant resources, depending on the amount of output data, it is also possible to decide whether to perform a direct comparison of the output data or a comparison of the checksum of the output data.

[0071] It is particularly advantageous if the comparison of the control parameters comprises a check as to whether errors occurring during data processing in the first data processing module and / or the second data processing module are below a tolerance limit, in which case a synchronous control parameter is generated, which means, inter alia, that in such cases a synchronous control parameter may be generated even if errors have occurred, provided that they are below the tolerance limit.

[0072] Also described herein is a method for operating the described data processing network, the method comprising at least the following steps: a) performing a data processing step by a first data processing module and generating first control parameters suitable for checking the performance of the data processing step by the first data processing module; b) independently of step a), performing the same data processing step by a second data processing module and generating second control parameters suitable for checking the performance of the data processing step by the second data processing module; c) performing a comparison of corresponding control parameters transmitted by the first data processing module and the second data processing module by a comparator module and providing, based on this comparison, at least one synchronized control parameter comprising control information relating to at least one performed data processing step.

[0073] Also described herein is a debug system for checking data processing by the above-mentioned data processing network, comprising a debug data processing module for performing data processing steps that are also correspondingly performed in the data processing network, an import module for importing debug data recorded by a recording module of the data processing network, and means for starting data processing by the debug system.

[0074] The debug system is a system that makes it possible to trace data processing steps performed in the data processing network described above, preferably using the same program code and preferably using the same compilation of this program code (possibly only up to a certain level). The restriction "up to a certain level" means that at lower, hardware-related layers, there may be differences between the execution of data processing steps on the hardware in use and their execution in the debug system, depending on the circumstances. However, it is preferably guaranteed (as far as possible) that differences at such levels do not cause problems when recognizing errors using the debug system.

[0075] In particular, a debug system likewise preferably has a structure with a data processing module for performing data processing steps and a comparator module for managing control parameters. A debug system typically does not have a structure with two parallel computing data processing modules for redundantly executing data processing steps. Such a structure is not particularly provided in a debug system, since the focus of the debug system is on testing or checking the execution of data processing steps in the data processing network. A high degree of error protection (high ASIL-D level) is generally not required here.

[0076] It is particularly advantageous if the debug system is designed such that at the start of data processing by the debug system, initial input data and states of the at least one first data processing module and / or the at least one second data processing module are imported into the debug data processing module.

[0077] Preferably, the debug system can locate initial input data to a data processing module or for a data processing step, as well as data related to the internal state of the data processing module, at a start point in the context, from which the data processing network operates exactly as it did before. For subsequent operation after the start point, typically, only the first recorded input data to the data processing network is still required. These are, for example, sensor data from the vehicle's sensors, which are permanently recorded during the vehicle's running operation. During data processing by the debug system, new input data are then continuously generated for downstream data processing modules. This is done by generating output data from the data processing module or data processing step in the debug system. Such output data periodically forms input data for subsequent data processing modules. Such input data generated by the debug system is called synthetic input data.

[0078] It is further preferred that the debug system is designed such that, during data processing by the debug system, a debug comparison is made between synthetic input data generated by the data processing by the debug system and input data permanently recorded in debug mode by the recording module.

[0079] In this way, the search for errors in data processing can be further improved. The described data processing network, debugging system, and technical environment are described below with reference to the figures, each showing a preferred, non-limiting exemplary embodiment of the present disclosure, which are merely schematic and each show individual aspects of the described data processing network. [Brief explanation of the drawings]

[0080] [Figure 1] 1 illustrates the data processing network described; [Figure 2]FIG. 1 illustrates the processing of individual data processing steps on a logical timeline. [Figure 3] FIG. 2 illustrates the processing of individual data processing steps by various data processing modules. [Figure 4] 1 is a flow diagram of a method described herein that is performed by a data processing network. [Figure 5] FIG. 1 illustrates a debug system as described. DETAILED DESCRIPTION OF THE INVENTION

[0081] 1 shows an illustrative data processing network 1 in a motor vehicle 23. By way of example, the data processing network 1 is shown here to be used to process data from sensors 19, from which a system is provided an output data receiver 20. Such an output data receiver 20 may be, for example, a system for autonomous driving operation or a similar system. The data processing network 1 may be used, for example, to transform sensor data into decision-relevant parameters, which may be output data 4 of the data processing network 1.

[0082] By data processing network 1 we also mean hardware components on which data processing network 1 or its components and modules can operate.

[0083] The data processing network 1 executes individual data processing steps 2 constructed in succession. Output data 4 of a data processing step 2 can become input data 3 of a further data processing step 2. Here, each data processing step 2 is realized by a number of data processing modules 5, 6 which are constructed as independently of one another as possible. Here, a first data processing module 5 and a second data processing module 6 are shown. It is also possible to provide more than two data processing modules which perform the data processing steps 2 (in parallel).

[0084] The data processing network 1 also includes further components, which will be explained in more detail on the basis of further figures, including, inter alia, a comparator module 7 and possibly also a synchronizer 27, both of which are only indicated here schematically.

[0085] 1 also shows a recording module 29, which is connected to each of the data processing modules 5, 6 and receives and records debug data 30 of the individual data processing steps, respectively, whereby the recording module 29 receives as debug data 30, inter alia, status data 30 and input data 3 of the data processing modules, as well as inter alia also control parameters related to the execution of the individual data processing steps 2.

[0086] FIG. 2 offers another representation of the described data processing network 1. In FIG. 2, three arrows are shown, one above the other, which define individual hardware components and at the same time represent the individual method steps a), b), and c) of the described method. At the same time, the arrows also provide a representation of the processes in the respective hardware components on a logical timeline 17. The upper arrow represents a first hardware component 12 in which a first data processing module 5 is implemented. The lower arrow represents a second hardware component 13 in which a second data processing module 6 is implemented. The central arrow represents a third hardware component 14 in which a comparator module 7 is implemented. In the first data processing module 5 and the second data processing module 6, a data processing step 2 of the data processing network 1 is executed, respectively. Whenever a data processing step 2 is completed, a control parameter 8 is transmitted to the comparator module 7, which then recognizes, by comparing the control parameter 8, whether the data processing step 2 has been executed correctly (i.e., without errors). The comparator module 7 then generates a synchronization control parameter 9, which is used to trigger a further data processing step 2, which then further processes the output data (not shown here) from the previous data processing step 2. The comparator module 8 and associated components can also be understood as a central unit 24 of the described data processing network 1. The synchronization control parameter 9 can be understood as a stimulus 25 for triggering the further data processing step 2.

[0087] Also shown schematically in FIG. 2 is a recording module 29 which records debug data 30 received from the first data processing module 5, the second data processing module 6 and the comparator module 7.

[0088] 3 shows in even more detail the parallel processing of the data processing step 2 by a first data processing module 5 and a second data processing module 6. It can be seen that the first data processing module 5 is implemented on a first hardware component 12 and the second data processing module 6 is implemented on a second hardware component 13. The first data processing module 5 and the second data processing module 6 should each process the same input data 3 and each produce the same output data 4.

[0089] The data processing step 2 or the data processing module 5, 6 can again be divided into a number of individual data processing components 18, each associated with a sub-step of the data processing. The data processing step 2 or the data processing module 5, 6 defined here is therefore already associated with a pre-grouping of sub-steps, selected or determined sensibly depending on the application, which sub-steps are executed by the data processing component 18. The pre-grouping of sub-steps is preferably selected in such a way that no data storage is necessary within the data processing step 2 or the data processing module 5, 6 and that for execution no data other than the input data is accessed.

[0090] The first data processing module 5 and the second data processing module 6 each generate control parameters 8, which are evaluated by a comparator module 7. The comparator module 7 is implemented on a third hardware component 14, which is independent of the first hardware component 12 and the second hardware component 13 and forms a central unit 24, preferably providing the high level of execution security (high ASIL level) already described above. In a preferred variant, each data processing module 5, 6 is preceded by a sequence module 11 for deriving the control parameters 8 from the data processing, and the comparator module 7 is preceded by a synchronizer 27. A task distribution module 22 can be additionally connected after the comparator module 7, which outputs a synchronization control parameter 9 or a stimulus 25 for triggering further data processing steps 2. The synchronizer 27, the comparator module 7, and the task distribution module 22 can be implemented together on the third hardware component 14 as the central unit 24 described above. Preferably, the described data processing network 1 is operated so that the data processing steps 2 are executed on available but underutilized hardware. A task distribution module 22 enables this distribution of the data processing steps 2 to the available hardware. Furthermore, the execution times of the implemented data processing steps 2 vary depending on the hardware. A synchronizer 27 sorts the incoming control parameters 8, so that the comparator module 7 then compares the control parameters 8 with each other in each case to generate the correct synchronized control parameters 9, even in cases of high hardware utilization. For this purpose, the control parameters 8 are transferred from the synchronizer 27 to the comparator module 7 as a control parameter tuple 28. It is not necessary for the input data 3 and the output data 4 to be transferred from one data processing step 2 to the next via the central unit 24 or the comparator module 7, respectively.For this purpose, there may be additional data transmission interfaces 26 between the data processing modules 5, 6 or the respective hardware components 12, 13 existing independently of the comparator module 7. In this case, access to the data provided via these data transmission interfaces 26 is preferably made when it has been determined in both data processing modules 5, 6 using the comparator module 7 that the processing of the data processing step 2 generating the respective output data 4 is error-free.

[0091] 4, yet another representation of the described method is chosen, in which method steps a), b) and c) are respectively performed for each data processing step 2. The actual execution of the data processing step 2 is always carried out redundantly by a first data processing module 5 and a second data processing module 6. A check is then made in each case by a comparator module 7 as to whether the data processing step 2 has been executed correctly, after which the next data processing step 2 is started.

[0092] 5 shows a debug system 33. A recording module 29 is again shown (although it is not part of the debug system 33 but part of the data processing network 1). Debug data 30 are imported into the debug system 33 via an import module 35. Within the debug system, debug data processing modules 34 are provided. The debug data processing modules 34 are designed to perform the same data processing steps 2 that were also performed in the data processing network. For this purpose, the import module 35 introduces state 31 and input data 3 into each debug data processing module 34 for the data processing step 2. Execution of the data processing step 2 by the debug system results in synthesized input data 36 of a further data processing step 2, which may then be supplied to evaluation by a debug comparison 37.

Claims

1. A system (1) for the implementation of a plurality of successive data processing steps (2), each of said data processing steps (2) serving to generate output data (4) from input data (3), the output data (3) of a first data processing step (2) being, at least in part, simultaneously the input data (3) of a further data processing step (2), at least one first data processing module (5) being provided for said implementation of each data processing step (2), said system (1) further comprising a comparator module (7), said first data processing module (5) being adapted to determine control parameters (8) of each of said data processing steps (2). to the comparator module (7), the comparator module (7) being designed to provide synchronization control parameters (9), the synchronization control parameters (9) comprising control information relating to at least one data processing step (2) to be performed, the system (1) comprising a recording module (29), in which a debug mode can be activated, the debug mode recording debug data (30), the debug data (30) comprising information relating to each execution of the data processing step (2) by the system (1).

2. 2. The system (1) according to claim 1, wherein a second data processing module (6) exists for at least a first data processing module (5), said second data processing module (6) being designed to perform the same data processing steps (2) as the first data processing module (5) assigned to it and to transmit control parameters (8) to said comparator module (7), said synchronized control parameters (9) being generated by at least one comparison of corresponding control parameters (8) transmitted by said first data processing module (5) and said second data processing module (6).

3. 2. The system (1) according to claim 1, wherein the recording module (29) is connected to the comparator module (7) and is designed to record the control parameters (8) occurring in the comparator module (7).

4. 3. The system (1) according to claim 2, wherein the recording module (29) is designed to record a state (31) of the at least one first data processing module (5) and / or the at least one second data processing module (6) upon activation of the debug mode.

5. 2. The system (1) according to claim 1, wherein the recording module (29) is designed to record initial input data (3) of each data processing step (2) of the system (1) upon activation of the debug mode.

6. 2. The system (1) according to claim 1, wherein the recording module (29) is designed to record input data of each data processing step (2) permanently while the debug mode is activated.

7. 2. The system (1) according to claim 1, wherein the data processing step (2) is assigned priority parameters, and information about each execution of the data processing step (2) is recorded in correspondence with the priority parameters.

8. 2. The system (1) according to claim 1, wherein a braking mode can be activated in the debug mode, which can ensure that information about each execution of the data processing step (2) is fully recorded.

9. 2. The system (1) of claim 1, wherein the first data processing module (5) is realized by a first hardware component (12), the second data processing module (6) is realized by a second hardware component (13), and the first hardware component (12) and the second hardware component (13) are physically separated from each other.

10. The system (1) of claim 2, wherein at least one of the first and second data processing modules (5, 6) comprises hardware components (12, 13) that are not ASIL-D compliant.

11. 2. The system (1) of claim 1, wherein the comparator module (7) is realized by a third hardware component (14) that is physically separated from the first hardware component (12) and the second hardware component (13).

12. The system (1) of claim 11, wherein the third hardware component (14) is ASIL-D compliant.

13. 3. The system (1) according to claim 2, wherein the comparator module (7) comprises a data memory (15) in which determined control parameters (8) are stored together with time information (16), thus obtaining a logical timeline (17) representing the order of processing of the data processing steps (2) by the first and second data processing modules (5, 6) of the system (1), and wherein the recording module (29) is designed to record, in the debug mode, the logical timeline (17) together with a flowchart (32) of the data processing steps (2) performed.

14. A debug system (33) for checking data processing performed by the system (1) according to claim 2, comprising: a debug data processing module (34) for performing the data processing steps (2) correspondingly performed in the system (1); an import module (35) for importing debug data (30) recorded by the recording module (29) of the system (1); and means for starting the data processing by the debug system (33).

15. 15. The debug system (33) of claim 14, wherein at the start of the data processing by the debug system (33), initial input data (3) and state (31) of the at least one first data processing module (5) and / or the at least one second data processing module (6) are imported into the debug data processing module (34).

16. 15. The debug system (33) of claim 14, wherein during the data processing by the debug system (33), a debug comparison (37) is performed between synthetic input data (35) generated by the data processing by the debug system (33) and input data (3) permanently recorded in the debug mode by the recording module (29).

Images