EP4420002A1 - Réseau de traitement de données destiné à effectuer un traitement de données - Google Patents

Réseau de traitement de données destiné à effectuer un traitement de données

Info

Publication number
EP4420002A1
EP4420002A1 EP22797706.3A EP22797706A EP4420002A1 EP 4420002 A1 EP4420002 A1 EP 4420002A1 EP 22797706 A EP22797706 A EP 22797706A EP 4420002 A1 EP4420002 A1 EP 4420002A1
Authority
EP
European Patent Office
Prior art keywords
data processing
module
data
debug
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22797706.3A
Other languages
German (de)
English (en)
Inventor
Raphael Diziol
Stefan Egenter
Michael Poehnl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of EP4420002A1 publication Critical patent/EP4420002A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1608—Error detection by comparing the output signals of redundant hardware
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G06F11/1641—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/263—Generation of test inputs, e.g. test vectors, patterns or sequences ; with adaptation of the tested hardware for testability with external testers
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/362—Debugging of software
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3698—Environments for analysis, debugging or testing of software

Definitions

  • Systems for driver assistance or automated driving consist of many individual software units, which can usually be described with graphs with regard to the data flow. These software units (often also called runnables, nodes or data processing components) are characterized by the fact that a quantity of input data is processed and a quantity of output data is generated from it.
  • the various software units regularly form a complex data processing network with which sensor data is processed in order to carry out actions based on the sensor data. Such actions can be, for example, control tasks within the scope of autonomous ferry operation of a vehicle.
  • Data processing in the data processing network usually includes a plurality of data processing steps or data processing tasks that build on one another and are executed with the data processing components.
  • the probability of systematic and sporadic hardware errors must not exceed a specified frequency that is related to the risk and the expected damage to the system functions. Because newly developed driver assistance systems are regularly used in parallel in a large number of vehicles and the risk has to be assessed in relation to the entire vehicle fleet equipped accordingly, the acceptable probability of the occurrence of hardware errors is extremely low. Compared to today's high-end processors, the computing power of commonly available microcontrollers that meet these security levels is very limited. Their maximum clock rate is around 10% (300 MHz vs. 3 GHz) and there are no internal optimizers, which are standard with off-the-shelf microprocessors (pP) and play a large part in their performance.
  • a major problem in this context is finding errors in the program code (debugging) due to the extremely large amounts of data that are processed in such applications, there is sometimes considerable effort to reproduce a specific undesirable behavior of such software for development purposes.
  • Such software runs for tests for example in vehicles that carry out a test operation.
  • very large amounts of data are recorded by camera sensors and processed in a data processing network.
  • this data is no longer available in an identical form for later re-running the test to reproduce the respective faulty behavior.
  • a data processing network is described here for the redundant and validated implementation of a plurality of consecutive data processing steps, each of which is used to generate output data from input data, with output data from a first data processing step being at least partially simultaneously input data for a further data processing step, with at least one first data processing step being required for the implementation of each data processing step
  • Data processing module is provided, wherein the data processing network further comprises a comparator module, wherein the first data processing modules are set up to transmit control parameters of the individual data processing steps to the comparator module and the comparator module is set up to provide a synchronized control parameter, which contains control information relating to at least one data processing step that has been carried out, the data processing network having a recording module in which a debug mode can be activated, with which debug data are recorded that contain information about each execution of a data processing step include the data processing network.
  • the data processing network has a second data processing module for at least one first data processing module, which is set up to carry out the same data processing step as the assigned first data processing module and to transmit a control parameter to the comparator module, with the synchronized control parameter being determined by at least one comparison of corresponding control parameters , which were transmitted by the first data processing modules and the second data processing modules, is generated
  • the special feature of the data processing network described here is the recording module, which permanently records debug data containing information on each execution of a data processing step. A replay of the respective data processing steps in the data processing network and/or in a test environment can later be achieved on the basis of this debug data.
  • the basic approach is that separate hardware (separate cores) is used for the first data processing module and the second data processing module, which has a high computing power and both perform the same calculation.
  • the comparator module compares the calculations and only if the calculation result is the same is it used for further data processing in the data processing network. The equality is monitored by the data processing module using the control parameters, and the synchronized control parameter is used in the data processing network to control the control flow of the data processing.
  • the points at which the first data processing module and the second data processing module provide the control parameters in order to then forward them to the comparator module are also regularly referred to as synchronization points.
  • a software lockstep is to be distinguished from a hardware lockstep.
  • a hardware lockstep requires significantly more complex hardware.
  • the hardware lockstep not claimed here is regularly implemented in such a way that hardware is used which executes each calculation step of the software programs operated on it twice. This means that the software program itself only runs once on the hardware. An operating system sees only one instance of the respective software program. Below the one operating system level, the hardware executes each step of the software twice.
  • the software lockstep described here means that the program is executed twice, twice at the operating system level. If necessary, two independent operating systems (a first operating system on the first data processing module with a first hardware/core and a second operating system on the second data processing module with a second hardware/core) can be operated, which each (and thus twice) execute the respective data processing steps .
  • a software lockstep can also be operated on an operating system, in which case the instruction may then be given at the operating system level to use different hardware (two different cores) for double execution.
  • a hardware lockstep always means that additional hardware (circuits, transistors, etc.) must be required for an additional redundant design, which is located below the operating system level and which the operating system cannot recognize as being separate from one another, but is different from the point of view of the operating system Operating system like a piece of hardware.
  • first data processing module and the second data processing module are designed with identical software and hardware that is identical in terms of its specification (identical cores) is also used. As long as the respective data processing module or the underlying hardware is functioning correctly, the same input data also produce the same output data in both data processing modules.
  • WCET Worst Case Execution Time
  • a data processing step for carrying out such an analysis requires, for example, a much longer time when a hundred traffic signs are visible at the same time than when only two traffic signs are in the field of view.
  • time slices would have to be designed using a WCET in such a way that sufficient time is provided for carrying out the data processing step for all conceivable relevant cases.
  • the next data processing step is carried out ad hoc, with the exact process not needing to be known a priori, which means that there is a high level of flexibility.
  • the order of execution is dictated by the primary engine.
  • the dependent secondary modules calculate “blindly” so to speak. Therefore the The order of execution - if at all - can only be checked using invariants or general rules. This results in the same security classification for the control flow as for the respective hardware used individually.
  • a high ASIL-D level cannot be achieved with such architectures. In other words: by recalculating with the secondary modules, it can be determined later that the calculations in the primary module could have been incorrect - but then it is already too late, because the results of the calculations would have been needed beforehand.
  • the comparison of the calculations can only take place after the end of the redundant calculation step and the subsequent communication of the results.
  • the time until an error is noticed in the calculation has doubled due to the principle. This results in an increased error latency, possibly also an unnecessary latency in the regular process.
  • the data processing network presented and the data processing methods implemented with it enable sufficient performance for highly autonomous driving.
  • the presented data processing network enables a combined time- and data-driven architecture. This means that, compared to approaches with an a priori fixed execution order, a flexible execution order is possible in the software lockstep.
  • a software lockstep approach that is carried out in parallel but is not based on time slices is selected, which is implemented on at least two microprocessors (the first data processing module and the second data processing module) as arithmetic units and a control component that runs on additional, trustworthy hardware (the comparator module) is running.
  • This control unit which corresponds to the safety target standard, synchronizes the process on the computing units and compares their results.
  • the redundant calculation steps are processed (quasi) simultaneously, thus resulting in no cascade and thus better latency behavior (see Figure 3).
  • the structure of the data processing network described corresponds to the decomposition of a security-critical task. This results in a reduced ASIL requirement for the individual computing units, so that an ASIL-D classification of the overall system can already be achieved with the high-performance processors that exist today.
  • Every calculation step that is started by a control event is data-deterministic. This means that with the same start state, identical input data always lead to the same output data.
  • control parameters includes an identity check and a synchronized control parameter requires an identity of the control parameters from the first data processing module and the second data processing module.
  • the data processing network is set up to use synchronized control parameters provided by the comparator module in order to carry out further data processing To control output data with further data processing steps of the data processing network.
  • the synchronized control parameter is a validity parameter which contains validity information relating to at least one data processing step that has been carried out.
  • the data processing network has at least one sequencing module which is set up in each case to sort and synchronize control parameters from the data processing modules and/or the data processing steps and then to forward these to the comparator module with a sorting, so that the comparator module can process synchronized control parameters independently of can determine the order in which the data processing modules have executed the data processing steps.
  • the sequencing module is used in particular to understand the order in which data processing steps are completed in the individual data processing modules and in particular on the hardware that is available in each case. In this way, availability of the hardware for carrying out further data processing tasks can be determined.
  • the sequencing module is assigned to the data processing module and transmits the control parameters to the comparator module or the (third) hardware component on which the comparator module is operated.
  • a synchronizer that synchronizes control parameters of the two data processing modules that belong to one another (as long as no error has occurred exactly corresponding) and forms control parameter tuples that are fed to the comparator module.
  • the synchronizer and the comparator module preferably together form a central unit that is operated on a (third) hardware component.
  • the synchronizer achieves flexibility in the execution order of the data processing steps.
  • the hardware of the respective data processing module can (if this hardware has finished carrying out a data processing step) also be used to carry out further data processing steps. Since the same data processing step is carried out on the first data processing module and the second data processing module, if the process is successful, the same control and data events are generated on each as on the other, but can be generated in a different order due to the parallel processing on the units.
  • the central unit (consisting of the comparator module and synchronizer) now temporarily stores events (control parameters) until the appropriate event (the corresponding control parameter) has arrived from all data processing modules.
  • the associated control parameters can then be compared and evaluated if they are the same, or the synchronized control parameter can be output.
  • an additional task distribution module which then plans and commissions the starting of the individual (next) data processing steps on the respective hardware when synchronized control parameters are available from the hardware module, so that a particularly good utilization of the hardware can be achieved.
  • the task distribution module preferably sends a type of stimulus to the individual data processing modules in order to activate them.
  • the use of the central processing unit or the third hardware component and the comparator module does result in a slight increase in the latency between the execution of two data processing tasks. Overall, however, this increase in latency is acceptable, especially when compared to common primary/secondary module architectures.
  • an error can be determined. Depending on the application, this can entail recalculation or an abort of data processing with the data processing network. Stimuli are found by the central processing unit in a certain way. Whenever a correct calculation result was determined by the comparator module by comparing control parameters and a synchronized control parameter could be calculated, a stimulus was found, so to speak, which triggers further data processing, the output data calculated with the respective first data processing module and the respective second data processing module required as input data.
  • the central unit not only evaluates all received data events (control parameters), but also events that indicate the end of a previous calculation step ('End' or 'DistributeSamples').
  • time events can be generated as stimuli for a time-driven execution.
  • the central unit manages the timeline (common logical timeline) of data processing already described above.
  • the recording module is connected to the comparator module and is set up to record control parameters that occur in the comparator module.
  • the comparator module and the control parameters occurring in the comparator module form a particularly good starting point for the recording module to record debug data.
  • a basic structure of the debug data to be recorded can already be generated via these control parameters.
  • the control parameters form a kind of basic data framework for the debug data, into which further data can then be fed for later execution of the respective data processing steps in a debug system (replay).
  • all data processing modules of the data processing network are preferably also connected to the recording module.
  • the comparator module itself usually does not receive the actually processed data, but only information about when which data goes into a module.
  • the data just the control parameters.
  • In order to record the actually processed data in the data processing modules there are preferably also data connections between the data processing modules and the recording module.
  • the recording module is set up to record a state of the at least one first data processing module and/or the at least one second data processing module when the debug mode is activated.
  • This state includes, in particular, internal memory states of the memory areas assigned to the respective data processing modules. This state can sometimes already include considerable amounts of data that have to be stored here. If necessary, the storage of such states can take a longer period of time because the data transmission of the data describing the state is so large. It may then be that the state is still saved while further data processing steps have already been completed.
  • the recording module preferably has a technology suitable for this.
  • the status usually has to be recorded by each data processing module. This is usually required to have the entire state of the data processing network available for debugging.
  • the (internal) states of the data processing modules are preferably recorded regularly and repeatedly. It is sufficient for starting the operation of a debug system if the status is recorded once at the start. Nevertheless, it is helpful (if enough bandwidth is available) to record other states (so-called keyframes) during operation. Thus, the debug system does not always have to be The beginning of the recording can be started with the recording module, but you can start at any keyframe.
  • the recording module is set up to record initial input data of each data processing step of the data processing network when the debug mode is activated.
  • the data processing network preferably comprises a multiplicity of data processing steps, which are superimposed on one another, of data processing from sensor data to the (final) output data of the data processing network.
  • Each data processing step or each data processing module has input data in this system.
  • the recording module is preferably designed in such a way that for each individual repeated data processing step, input data is recorded at least once (when the debug module is activated) as initial input data, so that a start state of the entire data processing network can be synthesized in a debug system with this input data.
  • the recording module is set up in such a way that input data of each data processing step is recorded permanently while the debug mode is activated.
  • Input data from each individual data processing step test are recorded permanently, in particular if the bandwidth available for recording data allows this.
  • a dynamic mode particularly preferably exists, which records input data while the debug mode is active whenever this is possible with regard to the available bandwidth, without the overall system being adversely affected.
  • priority parameters are assigned to the data processing steps and information about each execution of a data processing step is recorded according to these priority parameters.
  • the priority threshold up to which data is recorded in debug mode can then be adjusted. When a large amount of bandwidth is available, more data is written in debug mode than when the available bandwidth is limited and only minimal data necessary for synthesizing the states of the data processing network in a debug system is recorded in debug mode.
  • the data processing network is particularly preferred if a braked mode can be activated in the debug mode, with which it can be ensured that complete recording of information takes place for each execution of a data processing step.
  • the execution of the debug mode with the operation of the recording module and the recording of the debug data is a critical process for which the capacity for recording the data may have to be created. This can be achieved by the braked mode described. In this mode, the operation of the data processing network is regulated down to such an extent that the necessary information can be recorded completely in the debug mode.
  • first data processing modules are implemented with first hardware components and second data processing modules with second hardware components, with first hardware components and second hardware components being physically separate from one another.
  • At least one of the data processing modules has a hardware component that does not conform to ASIL-D.
  • comparator module is implemented using third hardware components that are physically separate from the first hardware components and the second hardware components.
  • the third hardware component conforms to ASIL-D.
  • the comparator module has a data memory in which determined control parameters are stored with time information, so that a logical timeline is created which depicts the order in which the data processing steps are processed with the data processing modules of the data processing network, with the recording module being set up for this purpose in debug mode to record this logical timeline with a flowchart of the data processing steps carried out.
  • the basic data structure formed with the control parameters is particularly helpful for the recording on this logical timeline.
  • the control parameters preferably also contain time information of the individual executions (start times and end times of the execution of the individual data processing steps with the data processing modules). With the help of this time information, all data processing steps recorded with the recording module, including the respectively processed data, can preferably be mapped on a logical timeline.
  • a hardware component of the data processing module is significantly more powerful than a hardware component of the comparator module.
  • the possible performance differences between the third hardware component of the comparator module and the (first and second) hardware components of the data processing modules depend on the respective application of the data processing network. It is usual, for example, for a processor clock of the first and second hardware component to be at least 5 times, possibly even 10 times, the processor clock of the third hardware component.
  • control parameters can be calculated as the checksum (CRC) for large amounts of data as output data, if necessary, and only these are used together with the unique packet identification ( alias Meta-Sample) is sent to the comparator module as a control parameter.
  • CRC checksum
  • the actual flow of output data from a data processing step as input data to the next data processing step can take place on the first hardware component and the second hardware component (and possibly also on other hardware components) independently of one another or in parallel, with data transmission interfaces possibly existing between different hardware components that also are independent of the central processing unit or the comparator module.
  • the central processing unit or the comparator module then does not check the original data but, for example, their checksums, which leads to a bit-by-bit comparison of the original content. It should be noted here that the first hardware component and the second hardware component must temporarily buffer the original data packets until they have been confirmed by the comparator and can be delivered.
  • the comparison of the control parameters includes a check as to whether a data processing in the first Data processing module and / or error that has occurred in the second data processing module is below a tolerance limit and in this case the synchronized control parameter is generated. This means in particular that in such cases the synchronized control parameter may be generated even though an error has occurred which is below the tolerance limit.
  • a method for operating a described data processing network having at least the following steps: a) carrying out a data processing step with a first data processing module and generating a first control parameter which is suitable for checking the carrying out of the data processing step with the first data processing module, b) independently of step a), performing the same data processing step with a second data processing module and generating a second control parameter which is suitable for checking the performance of the data processing step with the second data processing module; c) Carrying out a comparison of corresponding control parameters, which were transmitted by the first data processing module and the second data processing module, using a comparator module and based on this comparison, providing at least one synchronized control parameter, which contains control information relating to at least one data processing step that has been carried out.
  • a debug system for testing data processing with a described data processing network, having debug data processing modules for carrying out the data processing steps that are also executed accordingly in the data processing network, having an import module for importing debug data that was recorded with the recording module of the data processing network and Means for starting data processing with the debugging system.
  • the debug system is a system that enables the data processing steps carried out in the data processing network described above to be tracked, with the same program code preferably being used for this purpose and preferably (possibly only up to a certain level) the same compilations of this program code being used.
  • the restriction "up to a certain level” means that there may be differences in the execution of the data processing steps on the hardware in use and the execution in the debug system in lower hardware-related layers. However, it is then preferably ensured (as far as possible) that differences at such levels do not lead to problems when detecting errors with the aid of the debug system.
  • the debug system is built with data processing modules for carrying out the data processing steps and a comparator module for managing control parameters.
  • a structure with two parallel computing data processing modules for the redundant execution of the data processing steps is usually not available in the debug system. In particular, this is not provided for in the debug system because the focus in the debug system is on testing or checking the execution of the data processing steps in the data processing network.
  • a high level of failsafety (high ASIL-D level) is not usually required here.
  • the debug system is particularly advantageous if it is set up in such a way that initial input data and a state 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 modules when data processing with the debug system is started.
  • the debug system can preferably be put into a situation with the initial input data in the data processing modules or for the data processing steps and data relating to the internal state of the data processing modules at the start time, in which it works from there on in exactly the same way as the data processing network worked. For this subsequent work after the start time, only the first input data in the data processing network are then regularly required were recorded. These are, for example, sensor data from the vehicle's sensors, which are permanently recorded while the vehicle is in operation. During data processing with the debug system, new input data for downstream data processing modules are then continuously produced. This is done through the production of output data from data processing modules or
  • Such output data regularly form input data for subsequent data processing modules.
  • Such input data generated with the debug system is referred to as synthetic input data.
  • the debug system is set up such that during data processing with the debug system a debug comparison of input data generated synthetically with the data processing with the debug system and input data permanently recorded by the recording module in the debug mode takes place.
  • Fig. 3 the processing of a single data processing step with the various data processing modules
  • FIG. 4 a flow chart of the method described, which is carried out with the data processing network
  • FIG. and Fig. 5 a described debug system.
  • the 1 shows a described data processing network 1 in a motor vehicle 23. It is shown here by way of example that the data processing network 1 is used to process data from sensors 19 and that an output data receiver 20 is supplied with data by the system. Such an output data receiver 20 can be, for example, a system for autonomous ferry operation or a similar system.
  • the data processing network 1 is used, for example, to reduce the sensor data to decision-relevant parameters, which can be output data 4 from the data processing network 1 .
  • the data processing network 1 also includes hardware components on which the data processing network 1 or its components and modules can be operated.
  • the data processing network 1 carries out individual data processing steps 2 which build on one another. Output data 4 from a data processing step 2 can be input data 3 from a further data processing step 2 .
  • Each data processing step 2 is implemented here with a plurality of data processing modules 5, 6 that are executed as independently as possible. A first data processing module 5 and a second data processing module 6 are shown here. More than two data processing modules can also be provided, which carry out a data processing step 2 (in parallel).
  • the data processing network 1 also includes other components which will be explained in more detail with reference to the other figures. This includes, in particular, the comparator module 7 and possibly also a synchronizer 27, which are only indicated schematically here.
  • the recording module 29 receives as debug data 30 in particular status data of the data processing module 30 and input data 3, as well as in particular also control parameters regarding the execution of the individual data processing steps 2.
  • FIG. 2 chooses a different representation of the described data processing network 1.
  • three arrows are shown one below the other, which define the individual hardware components and at the same time also reflect the individual method steps a), b) and c) of the method described.
  • the arrows offer a representation of the processes on the respective hardware components on a logical timeline 17.
  • the upper arrow is a first hardware component 12 on which first data processing modules 5 are implemented.
  • the lower arrow is a second hardware component 13 on which second data processing modules 6 are implemented.
  • the middle arrow is a third hardware component 14 on which the comparator module 7 is implemented.
  • Data processing steps 2 of the data processing network 1 are carried out in first data processing modules 5 and second data processing modules 6 .
  • a control parameter 8 is transmitted to the comparator module 7, which then detects by comparing the control parameters 8 whether the data processing step 2 was carried out correctly (i.e. error-free).
  • the comparator module 7 then generates synchronized control parameters 9, which are used to trigger further data processing steps 2, which then further process output data from previous data processing steps 2 (not shown here).
  • the comparator module 8 and the associated components can also be understood as the central unit 24 of the data processing network 1 described.
  • the synchronized control parameters 9 can be understood as stimuli 25 for triggering further data processing steps 2 .
  • the recording module 29 which records debug data 30 which it receives from the first data processing module 5, the second data processing module 6 and from the comparator module 7 is also shown schematically in FIG.
  • FIG. 3 shows the parallel processing of a data processing step 2 by a first data processing module 5 and by a second data processing module 6 in even more detail. It can be seen that the first data processing module 5 is implemented on a first hardware component 12, while 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 each process the same input data 3 and should also generate the same output data 4 in each case.
  • a data processing step 2 or a data processing module 5, 6 can be further subdivided into a plurality of individual data processing components 18, each of which relates to sub-steps of data processing.
  • the data processing step 2 or the data processing module 5 , 6 as they are defined here therefore relate to pre-groupings of sub-steps that have been sensibly selected or specified depending on the application and are executed with the data processing components 18 .
  • the pre-grouping of sub-steps is preferably selected in such a way that no data storage is required within a data processing step 2 or a data processing module 5.6 and that, in particular, no data other than the input data is accessed for the execution.
  • the first data processing module 5 and the second data processing module 6 each generate control parameters 8 which are evaluated by the 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, which forms a central unit 24 and which preferably offers the higher security (higher ASIL level) of the execution already described above.
  • each data processing module 5, 6 is preceded by a sequencing module 11 for obtaining the control parameters 8 from the data processing and the comparator module 7 is preceded by a synchronizer 27 here.
  • the comparator module 7 can be followed by a task distribution module 22 which outputs synchronized control parameters 9 or stimuli 25 for triggering further data processing steps 2 .
  • Synchronizer 27, comparator module 7 and task distribution module 22 can be implemented together on the third hardware component 14 as the central unit 24 described.
  • the data processing network 1 described is preferably operated in such a way that data processing steps 2 are carried out on the hardware that is available and not fully utilized.
  • the Task distribution module 22 can cause this distribution of the data processing steps 2 to the available hardware.
  • the execution of the data processing steps 2 carried out takes a different amount of time on each piece of hardware.
  • the synchronizer 27 achieves a sorting of the incoming control parameters 8 so that the comparator module 7 then compares the correct control parameters 8 with one another, even when the hardware is heavily loaded, in order to generate correct synchronized control parameters 9 .
  • control parameters 8 are transferred from the synchronizer 27 to the comparator module 7 as control parameter tuples 28 . It is not necessary for input data 3 and output data 4 to be transferred from one data processing step 2 to the next data processing step 2 via the central processing unit 24 or the comparator module 7 .
  • FIG. 4 Another illustration of the method described is selected in FIG. 4, in which method steps a), b) and c) are carried out for each data processing step 2.
  • the actual data processing steps 2 are always executed redundantly in relation to one another with the first data processing module 5 and with the second data processing module 6.
  • a check is then carried out with the comparator module 7 as to whether the data processing step 2 has been carried out correctly before the next data processing step 2 is started.
  • the debugging system 33 is shown in FIG.
  • the recording module 29 is also shown here (although not belonging to the debug system 33 but to the data processing network 1).
  • Debug data processing modules 34 are provided in the debug system.
  • the debug data processing modules 34 are set up the same for this purpose Execute data processing steps 2, which were also carried out in the data processing network.
  • the import module 35 introduces the states 31 and the input data 3 into each debug data processing module 34 for the data processing steps 2 .
  • the system creates synthetic input data 36 of further data processing steps 2, which can then also be fed to an evaluation with the debug comparison 37.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention concerne un réseau de traitement de données (1) pour réaliser une multiplicité d'étapes de traitement de données successives (2) de manière redondante et validée, lesdites étapes de traitement de données étant chacune utilisées pour générer des données de sortie (4) à partir de données d'entrée (3), les données de sortie (3) issues d'une première étape de traitement de données (2) sont au moins partiellement en même temps que les données d'entrée (3) d'une autre étape de traitement de données (2), au moins un premier module de traitement de données (5) étant prévu pour effectuer chaque étape de traitement de données (2). Le réseau de traitement de données (1) comprend en outre un module comparateur (7), les premiers modules de traitement de données (5) sont conçus pour transmettre des paramètres de commande (8) des étapes individuelles de traitement de données (2) au module comparateur (7) et le module comparateur (7) est conçu pour effectuer un paramètre de commande (8) synchronisé qui contient des informations de commande relatives à au moins une étape de traitement de données effectuée (2). Le réseau de traitement de données (1) comprend un module d'enregistrement (29) dans lequel un mode de débogage peut être activé avec lequel sont enregistrées des données de débogage (30) contenant des informations sur chaque exécution d'une étape de traitement de données (2) avec le réseau de traitement de données (1).
EP22797706.3A 2021-10-18 2022-09-28 Réseau de traitement de données destiné à effectuer un traitement de données Pending EP4420002A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021211709.0A DE102021211709A1 (de) 2021-10-18 2021-10-18 Datenverarbeitungsnetzwerk zur Datenverarbeitung
PCT/EP2022/076891 WO2023066624A1 (fr) 2021-10-18 2022-09-28 Réseau de traitement de données destiné à effectuer un traitement de données

Publications (1)

Publication Number Publication Date
EP4420002A1 true EP4420002A1 (fr) 2024-08-28

Family

ID=84044447

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22797706.3A Pending EP4420002A1 (fr) 2021-10-18 2022-09-28 Réseau de traitement de données destiné à effectuer un traitement de données

Country Status (7)

Country Link
US (1) US12591492B2 (fr)
EP (1) EP4420002A1 (fr)
JP (1) JP7811643B2 (fr)
KR (1) KR20240093640A (fr)
CN (1) CN118414608A (fr)
DE (1) DE102021211709A1 (fr)
WO (1) WO2023066624A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3118749B1 (fr) * 2021-01-08 2023-01-06 Renault Sas Dispositif et procédé de calcul de paramètres de conduite
DE102024126963B3 (de) * 2024-09-19 2025-12-31 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Absichern einer Übertragung von Nutzdaten sowie dafür eingerichtetes Sendergerät und Kraftfahrzeug

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6591378B1 (en) * 2000-02-22 2003-07-08 Motorola, Inc. Debug controller in a data processor and method therefor
US6895530B2 (en) * 2003-01-24 2005-05-17 Freescale Semiconductor, Inc. Method and apparatus for controlling a data processing system during debug
US20040230867A1 (en) * 2003-05-15 2004-11-18 Ramin Soheili Method and system of using high-level code for independent debugging of a processor
DE102005037232A1 (de) 2005-08-08 2007-02-15 Robert Bosch Gmbh Verfahren und Vorrichtung zur Analyse von Abläufen in einem Rechnersystem mit mehreren Ausführungseinheiten
US8275977B2 (en) * 2009-04-08 2012-09-25 Freescale Semiconductor, Inc. Debug signaling in a multiple processor data processing system
US8405751B2 (en) 2009-08-03 2013-03-26 International Business Machines Corporation Image sensor pixel structure employing a shared floating diffusion
US20130097462A1 (en) * 2011-06-28 2013-04-18 Vivek Singh Embedded logic analyzer
JP6312550B2 (ja) * 2014-08-01 2018-04-18 ルネサスエレクトロニクス株式会社 半導体装置
US9459977B2 (en) * 2014-08-26 2016-10-04 Freescale Semiconductor, Inc. Data processing system with debug control
ITUB20154590A1 (it) * 2015-10-13 2017-04-13 Yogitech S P A Procedimento di esecuzione di programmi in un sistema elettronico per applicazioni in sicurezza funzionale comprendente una pluralita' di processori, relativo sistema e prodotto informatico
US10331532B2 (en) * 2017-01-19 2019-06-25 Qualcomm Incorporated Periodic non-intrusive diagnosis of lockstep systems
US10628277B2 (en) * 2018-03-29 2020-04-21 Arm Ltd. Device, system and process for redundant processor error detection
JP7042709B2 (ja) 2018-06-28 2022-03-28 ルネサスエレクトロニクス株式会社 半導体装置、制御システムおよび半導体装置の制御方法

Also Published As

Publication number Publication date
US20250004890A1 (en) 2025-01-02
DE102021211709A1 (de) 2023-04-20
CN118414608A (zh) 2024-07-30
JP7811643B2 (ja) 2026-02-05
KR20240093640A (ko) 2024-06-24
WO2023066624A1 (fr) 2023-04-27
JP2024538186A (ja) 2024-10-18
US12591492B2 (en) 2026-03-31

Similar Documents

Publication Publication Date Title
DE2908316C2 (de) Modular aufgebaute Multiprozessor-Datenverarbeitungsanlage
EP0512240B1 (fr) Système de commande pour véhicule à moteur
EP3211533B1 (fr) Architecture de système tolérant aux pannes destinée à commander une installation physique, en particulier une machine ou un véhicule automobile
EP3667568B1 (fr) Configuration d'un système de commande pour un véhicule automobile au moins partiellement autonome
EP4420002A1 (fr) Réseau de traitement de données destiné à effectuer un traitement de données
WO2022268270A1 (fr) Dispositif de commande et système d'assistance pour un véhicule
DE102008024193A1 (de) System mit konfigurierbaren Funktionseinheiten und Verfahren
WO2022084176A1 (fr) Réseau de traitement de données destiné à effectuer un traitement de données
DE102004051966A1 (de) Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
EP4266175B1 (fr) Procédé de fonctionnement par ordinateur d'une unité de mémoire et d'exécution de programmes d'application à vérification des erreurs de mémoire de la mémoire
WO2023066625A1 (fr) Réseau de traitement de données destiné à effectuer un traitement de données
WO2005001692A2 (fr) Procede et dispositif pour la surveillance d'un systeme reparti
WO2022063663A1 (fr) Procédé, module de traitement de données et réseau de traitement de données pour traiter des données
EP1812853B1 (fr) Procede, système d'exploitation et ordinateur pour l'execution d'un programme informatique
DE19801992C2 (de) Verfahren zur Verbesserung der Systemverfügbarkeit nach dem Ausfall von Prozessoren einer Prozessorplattform
DE102009061083B3 (de) Modifizieren periodischer Signale, die von einem Mikrocontroller erzeugt worden sind
DE102018112803A1 (de) Verfahren zum Bestimmen einer physikalischen Verbindungstopologie eines für die Steuergerätentwicklung eingerichteten, echtzeitfähigen Testgeräts
EP3575976A1 (fr) Procédé de détermination d'une topologie de connexion physique d'un appareil d'essai destiné à la mise au point d'appareil de commande
DE102023104360A1 (de) Verfahren und Optimierungsagent zum Optimieren eines Systems mit mehreren neuronalen Netzen
DE102022205517A1 (de) Verfahren zum Verarbeiten von Daten
DE102017116081A1 (de) Verfahren und Vorrichtung zum Konfigurieren einer Ausführungseinrichtung und zum Erkennen eines Betriebszustands derselben
DE102005054081B3 (de) Schaltungstechnisch realisierte Einheit zur nahezu verzögerungsfreien, nach Altersklassen sortierten Ausgabe zuvor sequenziell zugeführter Datenwortmengen
WO2024099723A1 (fr) Architecture de processeur redondant pour applications critiques en termes de sécurité
DE102024109658A1 (de) Fehlertolerantes verteiltes rechensystem basierend auf dynamischer umkonfiguration
WO2006120174A1 (fr) Procede de controle d'appareils de commande

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240521

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)