DE102020213371A1 - Device and method for controlling a technical system - Google Patents

Abstract

Method, for example computer-implemented method, for operating a device for controlling a technical system, in particular a motor vehicle or for a motor vehicle, comprising: using a quality of service, QoS, quality of service, and/or at least one variable characterizing the quality of service, for example partitions or to separate applications from one another at least temporarily, for example at least one application setting a quality of service, e.g. characterized by latency and/or bandwidth, for at least one peripheral component Method for controlling a technical system, in particular a motor vehicle.

Description

State of the art

There are control units that control sub-functions of a technical system, e.g. a vehicle. These each control specific sub-functions and/or associated applications.

Disclosure of Invention

Preferred embodiments relate to a method, for example a computer-implemented method, for operating a device for controlling a technical system, in particular a motor vehicle or for a motor vehicle, comprising: using a quality of service, QoS, quality of service, and/or at least one of the Size characterizing the quality of service, for example in order to at least temporarily separate partitions or applications (e.g. executable by the device) from one another, with at least one application setting a quality of service, e.g. characterizable by latency and/or bandwidth, for at least one peripheral component.

In further preferred embodiments, the method also includes: separating accesses by partitions or applications to the at least one peripheral component based on the quality of service and/or the at least one variable characterizing the quality of service.

In further preferred embodiments, the method also includes: specifying a first quality of service for a first peripheral component, specifying a second quality of service for a second peripheral component.

In further preferred embodiments, it is provided that the first quality of service is specified with regard to a bandwidth and/or a latency, and/or that the second quality of service is specified with regard to a bandwidth and/or a latency.

In further preferred embodiments it is provided that the method further comprises: emulating the quality of service and/or the at least one variable characterizing the quality of service using at least one counter, and/or using hardware-based management of the quality of service or the variable characterizing the quality of service.

In further preferred embodiments it is provided that the method further comprises at least one of the following elements: a) using at least a first counter for a latency associated with a first peripheral component, b) using a second counter for a bandwidth associated with the first peripheral component, c ) using at least a third counter for a latency associated with a second peripheral component, d) using a fourth counter for a bandwidth associated with the second peripheral component.

In further preferred embodiments it is provided that the method further comprises: evaluating the at least one counter, for example by a software component and/or a hardware component, the software component for example having a higher priority with regard to execution by the computing device than at least one application, and optionally operating or continuing to operate the device or at least one application of the device based on the at least one counter.

In further preferred embodiments it is provided that the method further comprises: comparing a counter value of the at least one counter with a comparison value and, if the counter value is greater than the comparison value, signaling, for example that the comparison value has been exceeded, to the at least one application and/or or a partition associated with the at least one application.

Further preferred embodiments relate to a device for carrying out the method according to the embodiments.

In further preferred embodiments, it is provided that the device has: a computing device (“computer”) having at least one computing core, a memory device assigned to the computing device for at least temporarily storing at least one of the following elements: a) data, b) computer program, in particular for execution of a method according to the embodiments. In further preferred embodiments, the computer program can also characterize at least one application (hereinafter also referred to as “application”) that is executed on the computing device, e.g. for controlling the technical system.

In further preferred embodiments, the device or the arithmetic unit has a plurality of arithmetic cores.

In further preferred embodiments, the storage device comprises a volatile memory (e.g. random access memory (RAM)) and/or a non-volatile memory (e.g. flash EEPROM).

In further preferred embodiments, the computing device has at least one of the following elements: microprocessor (μP), microcontroller (μC), application-specific integrated circuit (ASIC), system on chip (SoC), programmable logic module (e.g. FPGA, field programmable gate array), hardware circuit, or any combination thereof.

Further preferred embodiments relate to a computer-readable storage medium comprising instructions which, when executed by a computer, cause it to carry out the method according to the embodiments.

Further preferred embodiments relate to a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to the embodiments.

Further preferred embodiments relate to a data carrier signal which characterizes and/or transmits the computer program according to the embodiments. The data carrier signal can be received, for example, via an optional data interface of the device.

Further preferred embodiments relate to a method for controlling a technical system, e.g. a vehicle, in which a quality of service (QoS, Quality of Service) or at least one variable characterizing the quality of service is used to separate partitions or applications from one another at least temporarily , i.e. to separate.

According to further preferred embodiments, it can be advantageous in devices or systems in which several applications can run simultaneously, in particular to achieve the same runtimes of the applications or a definable distribution of resources (in particular independently of other applications), to also take into account one or more buses , which can be used in particular for data transmissions between components.

Since the runtime of applications is influenced by a number of factors in further preferred embodiments, these factors can also be addressed individually or in combination with one another in further preferred embodiments: core itself (hypervisor mechanism), access to memory (QoS), access to Modules in the computer - such as SPI, Safety, ...

According to further preferred embodiments, it is proposed to use a mechanism for separating accesses to memory, such as can be provided in bus systems or bus architectures of the device or the computing device, for separating accesses to the (peripheral) modules.

1. a) Applikation 1 stellt 15 Takte Latenz und 20 % Busbandbreite für Zugriffe bezüglich einer Peripheriekomponente ein,
2. b) Applikation 2 stellt 40 Takte Latenz und 70 % Busbandbreite auf dieselbe Peripheriekomponente ein.

In further preferred embodiments, at least one application, preferably several or all applications, sets a quality of service (“QoS”), eg characterizable by latency and/or bandwidth, for at least one peripheral component or at least one peripheral module. For example:

1. a) Application 1 sets a latency of 15 cycles and 20% bus bandwidth for access to a peripheral component,
2. b) Application 2 sets 40 clocks latency and 70% bus bandwidth on the same peripheral component.

In other words, in further preferred embodiments, the QoS or QoS mechanisms (e.g. implemented using hardware) can be used to control the bandwidth and/or latency of individual applications, in particular to separate peripheral accesses (applications accessing peripheral modules) and not to memory, whereby in particular it can also be used for the deterministic separation of applications and to reduce the effort involved in implementing a number of applications in one device or computing device, e.g. in a control unit.

In further preferred embodiments, it is proposed to use at least one counter to emulate a quality of service (QoS), which according to further preferred embodiments can be particularly useful when QoS cannot be implemented using hardware.

In further preferred embodiments it is proposed to emulate one or more QoS mechanisms, eg using at least one of the following elements: a) counters for latency and/or bandwidth are implemented, b) at a high priority level (eg above applications) evaluates a software these counters. A possible implementation according to further preferred embodiments provides, for example: x * 2 many registers (e.g. 32 bits wide) are implemented as counters per bus, with x characterizing a number of the partitions to be supported, and preferably in which or counts the register(s) per clock access of the respective assigned application. More preferably, the counter value is compared with an expected counter value every z ms, and if the counter value is greater than the expected counter value, the application and Eg the Partition Manager informs, in particular to initiate an alternative measure.

In further preferred embodiments - depending on the type of device or control or depending on the type of target system for the device or control - a time-synchronous grid or an angle-synchronous grid (e.g. with regard to one revolution of a crankshaft of an internal combustion engine) can be used. in particular for the QoS emulation described above by way of example using counter(s).

In further preferred embodiments, each time an action is pending on the bus with a (particularly predeterminable) partition ID, a counter is incremented by a predeterminable value, e.g. one, as a result of which a measure characterizing a bandwidth can be determined, for example.

In further preferred embodiments, starting with a request (request) on the bus of a (particularly specifiable) partition, the clock pulses are counted until the partition gets the bus (access granted). If, for example, the counted number of clocks is less than a specified latency, it is o.k. - if the value of the counted clock pulses is greater than the specifiable latency, this can be stored in further preferred embodiments and e.g. at the end of the set time interval it can be read out whether the latency in the considered time interval was ever larger than the preset time, and optionally, if so, by how much higher.

In further preferred embodiments, a preset, automatic comparison using hardware and/or the triggering of an interrupt is possible as an alternative or in addition.

In further preferred embodiments, one or more counters can be provided on at least one bus of the device or computing device.

In further preferred embodiments, the counters can be used in conjunction with appropriate software (and/or hardware) to evaluate, for example, a met allocated bandwidth and/or (meshed) latency.

Further preferred embodiments relate to use of the method according to the embodiments and/or the device according to the embodiments and/or the computer-readable storage medium according to the embodiments and/or the computer program according to the embodiments and/or the data carrier signal according to the embodiments for at least one of the following elements: a) enabling a deterministic runtime behavior of at least some, preferably all, applications of the device, b) avoidance of a new homologation for a first application, in particular when changing at least one further application, c) deterministic separation of applications, for example with regard to access to the at least one peripheral component.

Further features, application possibilities and advantages of the invention result from the following description of exemplary embodiments of the invention, which are illustrated in the figures of the drawing. All of the described or illustrated features form the subject matter of the invention, either alone or in any combination, regardless of how they are summarized in the claims or their back-reference and regardless of their wording or representation in the description or in the drawing.

• 1 schematisch ein vereinfachtes Blockdiagramm eines technischen Systems gemäß bevorzugten Ausführungsformen,
• 2 schematisch ein vereinfachtes Blockdiagramm einer Vorrichtung gemäß weiteren bevorzugten Ausführungsformen,
• 3A schematisch ein vereinfachtes Flussdiagramm mit Bezug auf Verfahrensaspekte gemäß weiteren bevorzugten Ausführungsformen,
• 3B, 3C, 3D, 3E, 3F, 3G, 3H, 3l jeweils schematisch ein vereinfachtes Flussdiagramm mit Bezug auf Verfahrensaspekte gemäß weiteren bevorzugten Ausführungsformen,
• 4A schematisch ein vereinfachtes Flussdiagramm mit Bezug auf Verfahrensaspekte gemäß weiteren bevorzugten Ausführungsformen,
• 4B schematisch ein vereinfachtes Flussdiagramm mit Bezug auf Verfahrensaspekte gemäß weiteren bevorzugten Ausführungsformen,
• 4C schematisch ein vereinfachtes Flussdiagramm mit Bezug auf Verfahrensaspekte gemäß weiteren bevorzugten Ausführungsformen,
• 4D schematisch ein vereinfachtes Flussdiagramm mit Bezug auf Verfahrensaspekte gemäß weiteren bevorzugten Ausführungsformen,
• 4E schematisch ein vereinfachtes Flussdiagramm mit Bezug auf Verfahrensaspekte gemäß weiteren bevorzugten Ausführungsformen,
• 4F schematisch ein vereinfachtes Flussdiagramm mit Bezug auf Verfahrensaspekte gemäß weiteren bevorzugten Ausführungsformen.

In the drawing shows:

• 1 schematically a simplified block diagram of a technical system according to preferred embodiments,
• 2 schematically a simplified block diagram of a device according to further preferred embodiments,
• 3A schematically a simplified flow chart with reference to method aspects according to further preferred embodiments,
• 3B , 3C , 3D , 3E , 3F , 3G , 3H , 3l each schematically a simplified flow chart with reference to method aspects according to further preferred embodiments,
• 4A schematically a simplified flow chart with reference to method aspects according to further preferred embodiments,
• 4B schematically a simplified flow chart with reference to method aspects according to further preferred embodiments,
• 4C schematically a simplified flow chart with reference to method aspects according to further preferred embodiments,
• 4D schematically a simplified flow chart with reference to method aspects according to further preferred embodiments,
• 4E schematically a simplified flow chart with reference to method aspects according to further preferred embodiments,
• 4F schematically shows a simplified flow chart with reference to method aspects according to further preferred embodiments.

Preferred embodiments relate to a method and/or a device 200 for controlling a technical system 1, for example a vehicle 1, in particular a motor vehicle, cf. 1 .

In further preferred embodiments, cf. 2 , it is provided that device 200 has: a computing device (“computer”) 202 having at least one (here, e following elements: a) data DAT, b) computer program PRG, in particular for carrying out a method according to the embodiments. In further preferred embodiments, the computer program PRG can also characterize at least one application (hereinafter also referred to as "application") APP1, APP2, APP3, which is executed at least temporarily on the computing device 202, e.g. for controlling the technical system 1 or components (e.g Braking system, internal combustion engine) thereof.

In further preferred embodiments, the device 200 or the arithmetic unit 202 has a plurality of arithmetic cores 202a, 202b, 202c. More than the in 1 The three computing cores 202a, 202b, 202c shown by way of example are also possible in further preferred embodiments.

In further preferred embodiments, the storage device 204 comprises a volatile memory 204a (e.g. random access memory (RAM)), and/or a non-volatile (NVM) memory 204b (e.g. flash EEPROM).

In further preferred embodiments, computing device 202 has at least one of the following elements or is designed as at least one of these elements: microprocessor (μP), microcontroller (μC), application-specific integrated circuit (ASIC), system on chip (SoC), programmable logic module (e.g. FPGA, field programmable gate array), hardware circuit, or any combination thereof.

Further preferred embodiments relate to a computer-readable storage medium SM, comprising instructions PRG which, when executed by a computer 202, cause it to carry out the method according to the embodiments.

Further preferred embodiments relate to a computer program PRG, comprising instructions which, when the program is executed by a computer 202, cause it to carry out the method according to the embodiments.

Further preferred embodiments relate to a data carrier signal DCS, which characterizes and/or transmits the computer program PRG according to the embodiments. The data carrier signal DCS can be received via an optional data interface 206 of the device 200, for example.

Other preferred embodiments 4A , relate to a method, for example a computer-implemented method, for operating a device 200 for controlling a technical system, in particular a motor vehicle 1 or for a motor vehicle 1, comprising: using 1300 a quality of service, QoS, quality of service, DG and/or or at least one variable DG-CG characterizing the quality of service DG, for example in order to at least temporarily separate partitions or applications APP1, APP2, for example of the device 200, with at least one application APP1 having a quality of service DG, for example characterizable by latency and/or bandwidth, for at least one peripheral component 208, 208a, 208b ( 2 ) sets.

In further preferred embodiments, the method further comprises: separating 1302 ( 4A ) of accesses by partitions PART1, PART2 or applications APP1, APP2 (e.g. applications APP1, APP2 assigned to the respective partitions PART1, PART2) to the at least one peripheral component 208 based on the quality of service DG and/or the at least one variable characterizing the quality of service DG DG-CG. As a result, access to the at least one peripheral component 208 can advantageously be based, for example, on a quality of service scheme or divided among different applications APP1, APP2, so that, for example, there is deterministic behavior even when the different applications APP1, APP2 access a peripheral component that can be shared, for example 208 results.

In further preferred embodiments, 4B , the method further includes: specifying 1310 a first quality of service DG1 for a first Peripheral component 208a, specification 1311 of a second quality of service DG2 for a second peripheral component 208b.

In further preferred embodiments it is provided that the specification 1310 of the first quality of service DG1 takes place with regard to a bandwidth and/or a latency, and/or that the specification 1311 of the second quality of service DG2 takes place with regard to a bandwidth and/or a latency.

In further preferred embodiments, 4C , it is provided that the method further comprises: emulating 1320 the quality of service DG and/or the at least one quantity DG-CG characterizing the quality of service by means of at least one counter Z1, and/or using 1322 hardware-based management of the quality of service DG or the quality of service DG characterizing quantity DG-CG, for example by means of a hardware component HW-K ( 2 ).

In further preferred embodiments, 4D , it is provided that the method further comprises at least one of the following elements: a) Using 1330 at least one first counter Z1-LAT for a with a first peripheral component 208a ( 2 ) associated latency, b) Use 1331 ( 4D ) a second counter Z1-BB for a bandwidth associated with the first peripheral component 208a, c) using 1332 at least a third counter Z2-LAT for a latency associated with a second peripheral component 208b, d) using 1333 a fourth counter Z2-BB for a bandwidth associated with the second peripheral component 208b.

In further preferred embodiments, 4E , it is provided that the method further comprises: evaluating 1340 the at least one counter Z1, for example by a software component SW-K ( 2 ) and/or one or the hardware component HW-K, with the software component SW-K, for example, having a higher priority with regard to execution by the computing device 202 than at least one application APP1, and, optionally, operating 1342 or continuing to operate the device 200 or at least one application App1 of the device 200 based on the at least one counter Z1.

In further preferred embodiments, 4F , it is provided that the method further comprises: comparing 1350 a counter value ZW1 of the at least one counter Z1 with a comparison value VW1, and, if the counter value ZW1 is greater than the comparison value VW1, signaling 1352, for example, that the comparison value VW1 has been exceeded, to the at least one application APP1 and/or a partition PART1 associated with the at least one application APP1.

Further preferred embodiments relate to a device 200 for carrying out the method according to the embodiments.

Further preferred embodiments, cf. 3A , relate to resetting 100, 102 (“reset”, “reset”) of at least one hardware component, in particular for at least one application APP1.

In further preferred embodiments, a reset 100, 102 of modules of the device 200 and/or possibly present, in particular external, circuits 208 (e.g. analog/digital converter, ADC) is carried out in such a way that several independent applications APP1, APP2, APP3 are operated and these preferably do not influence each other.

In further preferred embodiments, the device 200 is designed to individually reset each processor core 202a, 202b, 202c. In particular, further processor cores 202b, 202c that may be present in processor 202 are therefore not affected by the reset of one processor core 202a.

In further preferred embodiments, several areas or clusters can be provided, which are characterized, for example, by at least one processor core 202a and optionally with the at least one processor core associated memory 204a. In further preferred embodiments, the assignment of the memory to the at least one computing core can be logical and/or physical. In further preferred embodiments, at least one of the clusters can be reset independently of operation of the other clusters, in particular without impairing operation of the other clusters. In other preferred embodiments, this means that at least one cluster can be reset, for example, while other clusters that may be present can continue to be operated independently of the one cluster being reset, for example to run one or more applications.

In further preferred embodiments, at least one cluster can also have at least one circuit component or circuit part, for example a phase-locked loop (PLL, phased locked loop). In further preferred embodiments, when resetting the at least one cluster, the at least one circuit component can also be reset.

In further preferred embodiments, any peripheral modules that may be present, which can be assigned to the individual applications APP1, APP2, APP3, for example, can be reset in a supervisor mode and/or at least one application.

In further preferred embodiments, optionally present external components such as external logic can be reset via at least one separate data line, for example separate GPIO (general purpose input output), the resetting being performed according to further preferred embodiments, for example, by a supervisor mode or by an application APP1, APP2, APP3 is running. In other preferred embodiments, the GPIO (signal) can be routed to a reset input of the external component (e.g. external component or circuit) as a reset signal, for example.

In further preferred embodiments, a plurality of reset connections (“pins”) can be provided for any external components or circuits that may be present, so that, for example, the external circuits belonging to each application can be reset separately.

In further preferred embodiments, the resetting can be carried out by at least one of the sources mentioned below, which are in particular independent of one another: a) a signal, in particular hardware signal, which is triggered, for example, by a supervisor and/or a monitoring logic, b) by a bit which, when described, performs the reset function, c) by having software, particularly an application, set the bits to reflect the reset state.

In further preferred embodiments, specific functions can still be maintained in a targeted manner in the variant c) mentioned above. An example according to further preferred embodiments is an optional timer module (“timer”) which, for example, outputs a pulse width modulated (PWM) signal and which should not be interrupted, in particular not by the reset. According to further preferred embodiments, the other instances or parameters of the timer, in particular in the same module, which according to further preferred embodiments could also be reset by hardware, can be brought into a state via the register settings (writing or setting the bits), which, for example, corresponds to the reset values (“reinitialization”).

In further preferred embodiments, it is possible with the circuit functions listed above as examples according to further preferred embodiments, both by a supervisor and at least one application APP1 itself, the components or circuit parts necessary for operation of the application, in particular independently of the state and / or operation of other applications APP2, APP3 (these can be in reset, startup, ramp-down or normal function).

Further preferred embodiments relate to a method for resetting a device 200 for controlling a technical system 1, in particular a motor vehicle, for example a control unit, the resetting being carried out during ongoing operation (for example in one of several different possible operating states) of the device 200 or of the technical system 1 is running.

In further preferred embodiments, a plurality of applications APP1, APP2, APP3, in particular independent or at least partially dependent on one another, are operated on the device 200 simultaneously or at least with a temporal overlap.

In further preferred embodiments, additional components 208 or circuits that are optionally provided, in particular external components or circuits, for example peripheral components 208, can be assigned to at least one application APP1, which is at least temporarily managed by device 200 or its computing device 202 or at least one computing core 202a of the computing device 202 is executed.

In further preferred embodiments, the assignment of the components to the at least one application can also be carried out dynamically, ie while the device or the application is running.

In further preferred embodiments, the optionally provided further components or circuits can be reset, in particular separately from a supervisor and/or at least one application, in particular without affecting the runtime behavior of at least one, preferably several, in particular all further applications of the device.

In further preferred embodiments, the runtime behavior is characterized in that the same execution times are maintained, in particular with regard to a bandwidth and/or with regard to latency boundary conditions, with further preferred embodiments not requiring the same clock-exact behavior.

In further preferred embodiments, further applications APP3 of the device 200 continue to be operated while or when at least one other application APP2 of the device 200 is resetting the modules 208 and/or circuit parts assigned to it.

Further preferred embodiments, cf. 3B , relate to the behavior of memory areas of the memory device, in particular non-volatile memory areas (“NVM (non-volatile memory) memory area”) of the memory device, with one or more in particular of the non-volatile memory areas SB1 each being assigned to an application APP1 or to multiple applications 110 are or can be assigned.

In further preferred embodiments it is provided that at least one NVM memory area SB1 can be assigned to at least one, in particular precisely one, application APP1.

In further preferred embodiments, the NVM memory area is arranged in such a way that it is assigned to the at least one application, e.g. via a) an MPU (memory protection unit, memory protection device), and/or b) via a supervisor, in particular via an assignment of a partition ID can be.

In further preferred embodiments, the device 200 or the computing device 202 has three computing cores (“cores”) 202a, 202b, 202c, with an application being executed on each core, for example, and with each application being assigned a predefinable memory area, for example 4 megabytes ( MB), is assigned. For example, a first memory area SB1 is assigned to a first application APP1 and a second memory area SB2 to a second application APP1, cf. steps 110, 112 according to 3B .

In further preferred embodiments, a plurality of memory modules are provided in the memory device 204, in particular for the NVM memory areas 204b, with preferably at least two, preferably more than two, more preferably all of the memory modules being designed such that they are either complete or made up of smaller sub-modules are constructed or assembled.

In further preferred embodiments, the submodules have at least partially the same properties as a memory module to be assigned, e.g. with regard to common word line controls and/or common bit line readout circuits and/or common programming voltage supplies.

In further preferred embodiments, device 200 or computing device 202 is designed to reprogram the assigned memory areas or modules or submodules independently of the status of other memory areas or modules or submodules, with the resources required for this being available e.g. multiple times in are present in each memory area. It is therefore possible in further preferred embodiments for a first (memory) area to be reprogrammed while the applications from the other (memory) areas continue to run as if one application or the memory area assigned to it was not reprogrammed.

In further preferred embodiments, the one application or the memory area assigned to it can be reprogrammed from a supervisor and/or a partition manager and/or an application.

In further preferred embodiments, in particular by providing the resources described above, the method can also be carried out in an external memory (in particular with regard to the computing device or device), in particular NVM memory, which, for example, has several blocks and which, for example, has a separate Word line drive for the blocks and/or separate bit line readout circuits for the blocks. In further preferred embodiments, the NVM memory can be in the form of an LPDDR (low power double data rate) memory type.

1. a) das Verfahren wird, z.B. in einem Kraftfahrzeug, im laufenden Betrieb (z.B. in einem der verschiedenen Betriebszustände des Kraftfahrzeugs) durchgeführt
2. b) auf bzw. mittels der Vorrichtung bzw. Steuerung werden mehrere unabhängige oder abhängige Applikationen gleichzeitig oder wenigstens zumindest teilweise zeitlich überlappend betrieben,
3. c) verschiedene Speicherbereiche in und/oder außerhalb der Recheneinrichtung können, insbesondere flexibel und/oder dynamisch, den Applikationen zugeordnet werden,
4. d) verschiedene Speicherbereiche in und/oder außerhalb der Recheneinrichtung können, insbesondere getrennt bzw. unabhängig voneinander, von einem Supervisor und/oder wenigstens einer (insbesondere einer zugeordneten) Applikation umprogrammiert werden, insbesondere ohne das Laufzeitverhalten wenigstens einer anderen Applikation bzw. mehrerer bzw. aller anderen Applikationen der Vorrichtung bzw. Recheneinrichtung zu beeinflussen (das Laufzeitverhalten ist z.B. dadurch gekennzeichnet, dass dieselben Ausführungszeiten (insbesondere bezüglich einer vorgebbaren Bandbreite und/oder vorgebbarer Latenzrandbedingungen eingehalten werden, wobei insbesondere ein taktgenau selbes Verhalten gemäß weiteren bevorzugten Ausführungsformen nicht erforderlich ist),
5. e) wenigstens eine andere, vorzugsweise alle anderen, Applikationen der Vorrichtung bzw. Recheneinrichtung sind weiter funktional, wenn eine oder mehrere der Applikationen umprogrammiert werden.

Further preferred embodiments relate to a method for programming (and/or reprogramming) a device or a memory device of or for the device, the device being designed, for example, to control a technical system such as a motor vehicle, characterized by at least one of following aspects:

1. a) the method is carried out, for example in a motor vehicle, during operation (for example in one of the various operating states of the motor vehicle).
2. b) on or by means of the device or controller, several independent or dependent applications are operated simultaneously or at least partially overlapping in time,
3. c) different memory areas in and/or outside the computing device can be assigned to the applications, in particular flexibly and/or dynamically,
4. d) different memory areas in and/or outside of the computing device can be reprogrammed, in particular separately or independently of one another, by a supervisor and/or at least one (in particular an assigned) application, in particular without affecting the runtime behavior of at least one other application or several or to influence all other applications of the device or computing device (the runtime behavior is characterized, for example, by the fact that the same execution times (in particular with regard to a specifiable bandwidth and/or specifiable latency boundary conditions are observed, whereby in particular a clock-exactly the same behavior is not required according to further preferred embodiments),
5. e) at least one other, preferably all other, applications of the device or computing device continue to be functional if one or more of the applications are reprogrammed.

Further preferred embodiments, cf. 3C , refer to a fault collection and control unit, FCCU, 201 ( 2 ), i.e. a device for collecting and managing errors, in particular a division of FCCU resources. Step 115 off 3C symbolizes the use of the FCCU 201.

In further preferred embodiments, it is provided that the FCCU is designed to ensure independent (further) operation of applications of the device or computing device, whereby, for example, functionally deterministically separate reactions (in particular related to functional safety, "safety") e.g. for hardware errors. In other words, it can be made possible in further preferred embodiments that applications not affected by the hardware error, for example, can continue to be executed.

In further preferred embodiments, the FCCU is designed to collect hardware errors (“HW errors”) in individual modules such as core, RAM (memory), NVM (non-volatile memory) and/or peripheral modules 116 ( 3C ) and e.g. carry out error reactions 117, which can be set or specified, e.g. by means of a safety setup (e.g. setting up or configuring aspects relating to functional safety), e.g. activating one or more error pins (error connections), triggering an interrupt (interrupt request), the Triggering a reset or activating an NMI (Non-Maskable Interrupt Request).

In further preferred embodiments, error input signals are assigned to one or more applications, with error reactions (see e.g. the embodiments described above as examples) being able to be generated or output to the partitions and/or applications and/or assigned error pins.

As soon as, for example, in a first computing core (“Core 1”) 202a ( 2 ) of the three computing cores on which, for example, a first application APP1 (“application 1”) is running, an error is detected, a lockstep error in Core1 202a can be reported to the FCCU 201, for example. In further preferred embodiments, the FCCU 201 is configured such that the error can preferably only affect the actions assigned to the application 1 - e.g. the interrupt resources in the GIC ((generic) interrupt controller) of Core1 202a, the reset of Core1 , the NMI of Core1 or one or more error pins. In further preferred embodiments, it can be specified in a safety system setup—for example by a supervisor or the application 1—that this error triggers a reset of Core1, for example, or that a reset of Core1 should be triggered when this error occurs. In further preferred embodiments, other applications (eg “Application 2” and “Application 3”) are not influenced by the lockstep error in core 1 and preferably continue to run in the same time behavior.

According to further preferred embodiments, an error can be detected, for example, in a third processor core 202c (“Core 3”) of the three processor cores, to which a third application APP3 (“Application 3”) is assigned, eg an uncorrectable “double bit” error in the NVM memory area assigned to application 3. The FCCU 201 is preferably configured in such a way that the error, in particular only, is forwarded to the actions that are assigned to the application 3 . More preferably, an interrupt request (interrupt) to the application 3 can be triggered, for example by the FCCU, for example to call up an error handling routine for the double-bit error. In other preferred embodiments, the error handling routine may include additional tests, e.g to determine the severity of the safety influence caused by the error and, optionally, to either let application 3 continue to run accordingly or to reset it, for example, or to inform other applications, for example via the supervisor - for example by means of an interrupt - that these could possibly be affected (also by the error) and, for example, corresponding checks of the NVM memory assigned to applications 1 and 2 should be carried out.

1. a) das Verfahren wird, z.B. in einem Kraftfahrzeug, im laufenden Betrieb (z.B. in einem der verschiedenen Betriebszustände des Kraftfahrzeugs) durchgeführt,
2. b) auf bzw. mittels der Vorrichtung bzw. Steuerung werden mehrere unabhängige oder abhängige Applikationen gleichzeitig oder wenigstens zumindest teilweise zeitlich überlappend betrieben,
3. c) verschiedene Fehler bzw. Fehlerereignisse („Fehlerevents“) (z.B., RAM, Core, NVM, ...), die z.B. in und/oder außerhalb (externes NVM oder RAM) der Recheneinrichtung auftreten können, können jeweils wenigstens einer Applikation zugeordnet werden,
4. d) wenigstens eine, bevorzugt mehrere, insbesondere alle, Applikationen können, zumindest innerhalb ihrer Ressourcen, einen bzw. den Fehler bewerten und/oder eine entsprechende Fehlerreaktion einleiten und/oder wenigstens eine andere Applikation informieren, z.B. über mögliche Safety-Fehler, insbesondere in den ihnen zugeordneten Ressourcen,
5. e) wenigstens eine, bevorzugt mehrere, insbesondere alle, Applikationen können, durch wenigstens eine Andere Applikation über einen bzw. den Fehler informiert werden,
6. f) andere, insbesondere nicht von einem bzw. dem Fehler betroffene Applikationen können weiter laufen, insbesondere so weiter laufen, dass das Laufzeitverhalten, speziell die Latenzrandbedingungen eingehalten werden, wobei insbesondere ein taktgenau selbes Verhalten nicht erforderlich ist,

Further preferred embodiments relate to a method for troubleshooting an application in a device, e.g. controller, for a technical system, e.g. for a motor vehicle, characterized by at least one of the following aspects:

1. a) the method is carried out, e.g. in a motor vehicle, during operation (e.g. in one of the various operating states of the motor vehicle),
2. b) on or by means of the device or controller, several independent or dependent applications are operated simultaneously or at least partially overlapping in time,
3. c) Various errors or error events (“error events”) (e.g. RAM, core, NVM, ...), which can occur in and/or outside (external NVM or RAM) of the computing device, can each be assigned to at least one application will,
4. d) at least one, preferably several, in particular all, applications can, at least within their resources, evaluate one or the error and/or initiate a corresponding error reaction and/or inform at least one other application, e.g. about possible safety errors, in particular in the resources assigned to them,
5. e) at least one, preferably several, in particular all, applications can be informed about an error or the error by at least one other application,
6. f) Other applications, in particular those not affected by an error or the error, can continue to run, in particular in such a way that the runtime behavior, especially the latency boundary conditions, are observed, whereby in particular the same clock-accurate behavior is not required,

Further preferred embodiments, cf. 3D , relate to forwarding 120 of information I1-FUSI characterizing an operating state, in particular an operating state (“safety state”) with regard to functional safety (“safety”), an application (“application”) APP1, APP2, APP3 to at least one another unit such as an external unit 300 ( 2 ), in particular a unit 300 arranged externally to computing device 202 or device 200.

In further preferred embodiments, it is provided, in particular with regard to functionally deterministically separate safety reactions to hardware errors, that the unaffected application(s) continue to operate independently and, if applicable, the external unit(s) optionally connected thereto (such as a control of drivers, e.g. PHY for signals that carry a safety load and the conversion of the connections of the computing device ("computer pins") e.g. to a physical bus protocol) or also the activation of components such as ignition/injection in an internal combustion engine) to be able to guarantee, that these circuits assigned externally (with respect to the computing device) to the applications signal, for example, the safety status "Error" (can also be "Reset" in further preferred embodiments, but also in addition to the reset), in particular around the circuit parts assigned to the applications, that are not affected, not to influence.

In further preferred embodiments, three computing cores (3 cores) are provided by way of example, with 3 applications, one of the three applications running on each core. Furthermore, e.g. three error pins (connections, e.g. for signaling error states) are provided. In further preferred embodiments, external interfaces for a VCU (vehicle control unit) (e.g. application 1 on Core1) and an injection for a combustion application (e.g. application 3 on Core3) are provided by way of example.

In further preferred embodiments, the combustion application would like to switch off the injection, for example, in order to reduce the torque of the engine. For this purpose, for example, the error pin 3 (which, for example, has been assigned to application 3 during startup (i.e. when the device is started up)) is activated, which is preferably connected to the (external) injection circuit (IC) in such a way that this, in particular, is independent is switched off by the impulses that specify the injection timing and does not control the injection valves, for example. In further preferred embodiments, the VCU function continues to run on application 1 on core 1 at the same time—this VCU also transmits signals with a safety load, for example via a CAN driver. In further preferred embodiments, the error Pin1 (e.g. assigned to application 1 during startup) is not activated, so that the CAN signals coming from the computing device or the device forwarded via the currently not deactivated (to be deactivated with Error Pin1) CAN driver. As a result, the VCU application on Core1 is not affected by the error in application 3 (continues), and in particular the said CAN signals continue to be transmitted.

1. a) Die Signalisierung des Safety-Status kann bevorzugt z.B. für die externen Bauelemente („Peripheriemodule“) als Abschalt-Signal genutzt werden,
2. b) Die Signalisierung kann einzelnen Applikationen, die z.B. parallel auf der Recheneinrichtung laufen, zugeordnet sein, wobei insbesondere Peripheriemodule, die einer Applikation zugeordnet sind, unabhängig vom Zustand anderer Applikationen bzw. deren Peripheriemodule zurückgesetzt werden können,
3. c) eine Zuordnung kann, bevorzugt unveränderbar, nach einem Reset vorgenommen werden,
4. d) Aspekte dieser Ausführungsformen können auch für externe Security-Bauelemente wie z.B. externe Crypto Bauelemente (Kryptografie-Beschleuniger, Hardware-Sicherheitsmodul), Schnittstellen, genutzt werden,
5. e) Verwendung sowohl in Bezug auf Aspekte der funktionalen Sicherheit („FUSI“, „Safety“) als auch in Bezug auf Aspekte der Sicherheit z.B. gegen Manipulationen („Security“).

Further preferred embodiments relate to a method for signaling, in particular forwarding, the safety status of at least one application to units or components outside the computing device or device, characterized by at least one of the following aspects:

1. a) The signaling of the safety status can preferably be used, for example, as a switch-off signal for the external components ("peripheral modules"),
2. b) The signaling can be assigned to individual applications that run in parallel on the computing device, for example, with peripheral modules assigned to an application being able to be reset independently of the status of other applications or their peripheral modules,
3. c) an assignment can be made, preferably unchangeable, after a reset,
4. d) Aspects of these embodiments can also be used for external security components such as external crypto components (cryptography accelerator, hardware security module), interfaces,
5. e) Use both in relation to aspects of functional safety (“FUSI”, “Safety”) and in relation to aspects of security, eg against manipulation (“Security”).

Further preferred embodiments, cf. 3E , relate to a method for controlling a technical system 1, for example a vehicle 1, in which at least one peripheral module 206 is assigned to at least one, in particular precisely one, application APP1, see step 125 from FIG 3E . The applications can preferably each run in separate partitions on the computing device 202 .

In further preferred embodiments, the at least one peripheral module 206 is, for example, at least one of the following elements: timer (timer module), communication interfaces 206, GPIO ports (general input and/or output connections).

In this way, it can preferably be achieved that a number of applications APP1, APP2, APP3 do not mutually influence one another when they are operated on the computing device 202.

1. 1. Betrieb eines Analog/Digital-Wandlers (ADC): Wenn mehrere Applikationen auf die Ressourcen des ADC (z.B. Kanäle/Eingänge und/oder Steuerregister) zugreifen, dann kann die eine Applikation z.B. die Einstellungen einer anderen Applikation überschreiben - z.B. Kanalzuordnung, Sample Time (Abtastrate), Conversion Time (Umwandlungszeit), ...
2. 2. CAN (Controller Area Network): Wenn in mehreren Applikationen CAN-Identifier auf demselben CAN Bus genutzt werden, können in einem CAN Modul z.B. Queue- Einträge vorgenommen werden, wobei die Software einer Partition (d.h., z.B. eine Applikation) die Settings einer anderen Applikation überschreiben kann.

Examples of undesired mutual interference, which can be avoided according to further preferred embodiments, are:

1. 1. Operation of an analog/digital converter (ADC): If several applications access the resources of the ADC (e.g. channels/inputs and/or control registers), then one application can, for example, overwrite the settings of another application - e.g. channel assignment, sample Time (sampling rate), Conversion Time (conversion time), ...
2. 2. CAN (Controller Area Network): If CAN identifiers are used in several applications on the same CAN bus, queue entries can be made in a CAN module, for example, whereby the software of a partition (ie, for example an application) changes the settings of a can be overwritten by another application.

In further preferred embodiments it is provided that at least one peripheral module, preferably completely, can be assigned to a partition or application.

In further preferred embodiments, modules are provided in the device or computing device, such as SPI (serial peripheral interface), LIN (local interconnect network), CAN, ADC, which, for example, can preferably be completely assigned to an application, in particular because the resources of these modules either be used completely by the partition or application (application), or these modules are present several times, in particular so frequently, that corresponding individual modules can be completely assigned to a partition or application (application).

• - Zuordnung wenigstens eines, vorzugsweise mehrere bzw. aller Module zu einer Partition bzw. Applikation (insbesondere in dem Modul), wobei insbesondere das Modul z.B. nur Schreib- und/oder Lesebefehle von einem Bus (z.B. Datenbus zur Anbindung des Moduls an Komponente(n) der Recheneinrichtung bzw. Vorrichtung) akzeptiert, die mit einer vorgebbaren Kennung, z.B. „Partition ID“, kommen, die z.B. vorher im System Setup von einem Partition Manager dem Modul zugewiesen worden ist.

In further preferred embodiments, the following mechanisms are proposed, in particular to separate these modules according to a goal of a deterministic function:

• - Assignment of at least one, preferably several or all modules to a partition or application (in particular in the module), with the module in particular only receiving write and/or read commands from a bus (e.g. data bus for connecting the module to component(s). ) of the computing device or device) that come with a definable identifier, eg “Partition ID”, which has been assigned to the module beforehand in the system setup by a partition manager.

In further preferred embodiments, modules, preferably complete modules, are thus assigned, in particular permanently (that is to say statically), to partitions, in particular to a partition or application.

In further preferred embodiments it can be provided that (peripheral) modules can be assigned to a number of applications, for example predeterminable or controllable by at least one hardware function such as an address range restriction.

In further preferred embodiments, there are e.g can become.

• - Zuordnung der Module zu den Partitionen bzw. Applikationen über Adressbereiche, und/oder
• - Anordnung der Ressourcen in einem Modul so, dass die Ressourcen, die zu einer Partition (bzw. Applikation) zugeordnet werden, dass diese in einem Adressbereich nahe beieinander (z.B. benachbart) liegen, und/oder
• - Die Zuweisung des Adressbereiches bzw. der Adressbereiche kann z.B. extern über eine Bus-Brücke erfolgen, und/oder über eine Speicherschutzeinrichtung (MPU), die z.B. sicherstellt, dass die internen Master/Slave(s), die nicht der zugeordneten Partition bzw. Applikation gehören, auf diesen Adressbereich nicht Lesen und/oder Schreiben können.

In order to separate these modules according to further preferred embodiments, in particular with the aim of a deterministic function, the following mechanism is proposed:

• - Assignment of the modules to the partitions or applications via address ranges, and/or
• - Arrangement of the resources in a module so that the resources that are assigned to a partition (or application) that they are close to each other (eg adjacent) in an address range, and/or
• - The address range or ranges can be assigned externally via a bus bridge, for example, and/or via a memory protection device (MPU), which ensures, for example, that the internal master/slave(s) that are not assigned to the partition or application, cannot read and/or write to this address range.

In further preferred embodiments, (peripheral) modules can therefore be assigned to applications or partitions via a restriction of the address areas, preferably internal to the module.

In further preferred embodiments, there are also modules, for example, which can be separated from one another via software (SW) mechanisms, these modules being used, for example, by a number of partitions or applications. An example according to further preferred embodiments is e.g. Ethernet without using implemented queues, another example according to further preferred embodiments is a bus for interprocessor communication, or also a CAN module in which a SW assignment, in particular of the individual ID(s) , makes sense because, for example, there are not enough CAN modules in the system.

1. a) Diese Module, insbesondere im Startup (Hochfahren), durch ein Konfigurationstool so zu konfigurieren, dass die Randbedingungen aller Partitionen bzw. Applikationen, die diese Ressourcen nutzen, berücksichtigt werden,
2. b) Bsp. CAN/Ethernet: Bandbreite und/oder Latenz aus der Anforderung wird so implementiert, dass die Anforderungen erfüllt werden - Aufteilung der Message ID auf die Queues der Module mit den entsprechenden zu vergebenden Prioritäten,
3. c) Im laufenden Betrieb wird über den Partition Manager (SW, die in einem Rechte-Modus über den Partitionen bzw. Applikationen läuft) das Schreiben-/Lesen auf diese Ressourcen geregelt - hier gibt es bevorzugt mehrere Möglichkeiten, den Partition Manager aufzurufen - z.B. über einen Call oder auch über Trap/Emulate (es wird bewusst auf eine Ressource geschrieben, die gesperrt ist, und so der höhere Priviledge Level zur Lösung des Zugriffskonfliktes aufgerufen,
4. d) Eine weitere Möglichkeit gemäß weiteren bevorzugten Ausführungsformen ist, das Schreiben und/oder Lesen über das Aufsetzen von DMA Kanälen im laufenden Betrieb zu regeln - diese DMA Kanäle werden dann z.B., bevorzugt nur, bei bestimmen Triggern aktiviert, und das Lesen und/oder Schreiben umfasst dann z.B. nur spezielle Ressourcen in dem Modul, und z.B. Schreiben-/Lesen der Daten dann von fest den einzelnen Partitionen zugeordneten Adressbereichen.

In further preferred embodiments it is therefore proposed:

1. a) To configure these modules, in particular during startup, using a configuration tool in such a way that the boundary conditions of all partitions or applications that use these resources are taken into account,
2. b) E.g. CAN/Ethernet: bandwidth and/or latency from the request is implemented in such a way that the requirements are met - allocation of the message ID to the queues of the modules with the corresponding priorities to be assigned,
3. c) During operation, writing/reading to these resources is regulated via the Partition Manager (SW that runs in a rights mode via the partitions or applications) - here there are preferably several options for calling the Partition Manager - e.g via a call or via trap/emulate (a resource that is locked is deliberately written to and the higher privilege level is called up to solve the access conflict,
4. d) A further possibility according to further preferred embodiments is to regulate the writing and/or reading by setting up DMA channels during operation—these DMA channels are then, for example, preferably only activated with specific triggers, and the reading and/or Writing then includes, for example, only special resources in the module, and then, for example, writing/reading the data from address areas permanently assigned to the individual partitions.

In further preferred embodiments it is therefore proposed: allocation of resources (e.g. peripheral modules) of the device or computing device to a plurality of partitions or applications, with SW functions and HW functions being used

Further preferred embodiments, cf. 3F , relate to a method for controlling a technical system, for example a vehicle, in which a quality of service (QoS, Quality of Service) or at least one variable characterizing the quality of service is used, see step 130, partitions or application, at least temporarily separate from each other, i.e. separate.

According to further preferred embodiments, it can be advantageous in devices or systems in which several applications can run simultaneously, in particular to achieve the same runtimes of the applications or a definable distribution of resources (in particular independently of other applications), to also take into account one or more buses , which can be used in particular for data transmissions between components.

Since the runtime of applications is influenced by a number of factors in further preferred embodiments, these factors can also be addressed individually or in combination with one another in further preferred embodiments: core itself (hypervisor mechanism), access to memory (QoS), access to Modules in the computer - such as SPI, Safety, ...

According to further preferred embodiments, it is proposed to use a mechanism for separating accesses to memory, such as can be provided in bus systems or bus architectures of the device or the computing device, for separating accesses to the (peripheral) modules.

1. a) Applikation 1 stellt 15 Takte Latenz und 20 % Busbandbreite für Zugriffe bezüglich einer Peripheriekomponente ein,
2. b) Applikation 2 stellt 40 Takte Latenz und 70 % Busbandbreite auf dieselbe Peripheriekomponente ein.

In further preferred embodiments, at least one application, preferably several or all applications, sets a quality of service (“QoS”), eg characterizable by latency and/or bandwidth, for at least one peripheral component or at least one peripheral module, see the optional step 132 according to 3F . For example:

1. a) Application 1 sets a latency of 15 cycles and 20% bus bandwidth for access to a peripheral component,
2. b) Application 2 sets 40 clocks latency and 70% bus bandwidth on the same peripheral component.

In other words, in other preferred embodiments, the QoS or QoS mechanisms (e.g. implemented using hardware) can be used to control the bandwidth and/or latency of individual applications APP1, in particular to separate peripheral access (application access to peripheral modules ) and not to memory, whereby in particular it can also be used for the deterministic separation of applications and to reduce the effort involved in implementing a number of applications in one device or computing device, e.g. in a control unit.

In further preferred embodiments, it is proposed to use at least one counter to emulate a quality of service (QoS), which according to further preferred embodiments can be particularly useful when QoS cannot be implemented using hardware.

In further preferred embodiments it is proposed to emulate one or more QoS mechanisms (cf. also block 1320 according to 4C ), eg by means of at least one of the following elements: a) Counters for latency and/or bandwidth are implemented, cf. eg the reference symbols Z1-LAT, Z1-BB, Z2-LAT, Z2-BB according to FIG 4D, b ) at a high priority level (e.g. above applications) software SW-K evaluates these counters.

A possible implementation according to further preferred embodiments provides, for example: per bus x * 2 many registers (e.g. 32 bits wide) are implemented as counters, where x characterizes a number of the partitions to be supported, and preference is given to the counts the register(s) per clock access of the respective assigned application. More preferably, for example, the counter value is compared with an expected counter value every z ms, and if the counter value is greater than the expected counter value, the application and, for example, the partition manager are informed, in particular in order to initiate an alternative measure.

In further preferred embodiments--depending on the type of device 200 or controller or depending on the type of target system 1 for the device or controller--a time-synchronous grid or an angle-synchronous grid (e.g. with respect to one revolution of a crankshaft of an internal combustion engine) can be used in particular for the QoS emulation described above by way of example using counter(s).

In further preferred embodiments, each time an action is pending on the bus with a (particularly predeterminable) partition ID, a counter is incremented by a predeterminable value, e.g. one, as a result of which a measure characterizing a bandwidth can be determined, for example.

In further preferred embodiments, starting with a request (request) on the bus of a (particularly specifiable) partition, the clock pulses are counted until the partition gets the bus (access granted). If, for example, the counted number of clocks is less than a specified latency, it is o.k. - if the value of the counted clock pulses is greater than the specifiable latency, this can be stored in further preferred embodiments and e.g. at the end of the set time interval it can be read out whether the latency in the considered time interval was ever larger than the preset time, and optionally, if so, by how much higher.

In further preferred embodiments, a preset, automatic comparison using hardware and/or the triggering of an interrupt is possible as an alternative or in addition.

In further preferred embodiments, one or more counters can be provided on at least one bus of the device or computing device.

In further preferred embodiments, the counters can be used in conjunction with appropriate software (and/or hardware) to evaluate, for example, a met allocated bandwidth and/or (meshed) latency.

Further preferred embodiments, cf. 3G , relate to a method and a device for controlling a technical system, e.g. a vehicle, in which a memory protection device (MPU) is provided, the memory protection device being used in particular for this purpose, cf. step 135, access rights with regard to at least one bus system of device 200 or , computing device 202 .

An advantage of operating several applications on one device or computing device according to further preferred embodiments is a short latency of data exchange and a high bandwidth of the exchange, which means that controllers, for example, can be calculated in shorter time frames than specified in conventional systems, since the data from the other Applications are available relatively quickly.

In further preferred embodiments, in order to make this possible and in particular to ensure that multiple applications do not impermissibly influence one another, it is proposed to use an MPU within the computing device or outside of the computing device, e.g. in the area of the bus system, to restrict access rights.

In further preferred embodiments, the following sequence can be used as an example: A core-external MPU is provided, e.g. in a bus interface, with two applications being provided, each of which runs on a core.

In further preferred embodiments, the MPU can be configured in such a way, e.g. during a system start, that regions in the local memory assigned to the other core are allocated for writing and regions in its own memory are released for reading. This means that each application can then, for example, read the data of the other core and write data to it locally, in particular without other (memory) areas being overwritten.

In further preferred embodiments, the following is therefore proposed: a method for using a memory area allocation by means of an MPU to ensure a deterministic data exchange between a number of applications running on the computing device or the device.

In other preferred embodiments, the following is therefore proposed: a method for ensuring deterministic memory accesses and/or data exchanges between different applications using at least one MPU. In this context, “deterministic” is particularly preferably related to the application timing (ie the temporal behavior of the application(s)), and in particular not to a specific number of cycles for accessing the respective resources.

Further preferred embodiments, cf. 3H , relate to a method and a device for controlling a technical system, for example a vehicle, in which at least one hardware accelerator unit HSM ( 2 ) is used to speed up a startup of the system or device 200 .

In modern (particularly automotive) systems, it happens that the existing software of a device is replaced by other software (“tuning”), e.g. to have more power available in the application (e.g. more power, PS). One method of detecting and, if necessary, preventing this is to check the software code before booting (starting or booting up) the system to see whether it is the code that is actually supposed to be executed or whether the Code has been manipulated, for example as part of a tuning measure.

A method according to further preferred embodiments for checking the SW code provides for determining or calculating at least one checksum (checksum) over a predefinable memory area or the (in particular entire) memory. A problem can be that the determination or calculation of the checksum takes a comparatively long time, which means that the boot process is lengthened. In further preferred embodiments, a boot process should be completed in 30 ms - 100 ms, for example. However, the checksum calculation may add a significant number of milliseconds.

It is therefore proposed in further preferred embodiments to provide at least one hardware accelerator unit HSM and to calculation of the checksum(s) ("HW Checksum Accelerator"). In further preferred embodiments, a plurality of hardware accelerator units can also be provided which, if necessary, each process a part of the memory to be checked or form a checksum for the corresponding part. More preferably, the checksum is calculated using the at least one hardware accelerator unit before starting the application(s) APP1, APP2, APP3.

In further preferred embodiments, hardware accelerator units can also be assigned to different partitions or applications.

Further preferred embodiments, cf. 3I , relate to a method and a device 200 for controlling a technical system 1, for example a vehicle 1, in which a mechanism, preferably in the interface (interface) of the module 208, is implemented in at least one hardware module 208 or a peripheral component , cf. step 150 according to 3I , by means of which orders from several partitions or applications APP1, APP2, APP3 can be placed, which in particular cannot be overwritten or influenced by other partitions or applications. In further preferred embodiments, the mechanism can also be referred to as “transfer window(s)”.

In further preferred embodiments, the HW module (or a controller of the module such as a microcontroller of the module) or the peripheral component is designed to process these orders according to a predetermined rule, e.g. in a round robin process, which is advantageous for the (external) applications a deterministic time behavior is shown.

1. a) Der Adressbereich des Transfer Window kann wahlweise verschiedenen Applikationen/Partitionen zugeordnet werden,
2. b) In dem Modul werden, z.B. mittels SW, nach einem vorgebbaren Verfahren, z.B. einem Round-Robin-Verfahren, die Aufgaben abgearbeitet.

Further preferred embodiments provide for an implementation of Transfer Windows in at least one HW module with at least one of the following aspects:

1. a) The address range of the transfer window can be assigned to different applications/partitions,
2. b) The tasks are processed in the module, for example by means of software, according to a predefinable method, for example a round-robin method.

Further preferred embodiments relate to use of the method according to the embodiments and/or the device according to the embodiments and/or the computer-readable storage medium according to the embodiments and/or the computer program according to the embodiments and/or the data carrier signal according to the embodiments for at least one of the following elements: a) enabling a deterministic runtime behavior of at least some, preferably all, applications of the device, b) avoidance of a new homologation for a first application, in particular when changing at least one further application.

Claims (13)

Method, for example computer-implemented method, for operating a device (200) for controlling a technical system (1), in particular a motor vehicle or for a motor vehicle (1), comprising: using (130; 1300) a quality of service, QoS, quality of service (DG), and/or at least one variable (DG-CG) characterizing the quality of service, for example in order to separate partitions or applications from one another at least temporarily, with at least one application (APP1) having a quality of service (DG), e.g. characterizable by latency and /or bandwidth for at least one peripheral component (208) (132). procedure after claim 1 , further comprising: separating (1302) accesses from partitions (PART1, PART2) or applications (APP1, APP2) to the at least one peripheral component (208) based on the quality of service (DG) and/or the at least one variable characterizing the quality of service (DG-CG). Method according to at least one of the preceding claims, further comprising: specifying (1310) a first quality of service (DG1) for a first peripheral component (208a), specifying (1311) a second quality of service (DG2) for a second peripheral component (208b). procedure after claim 3 , wherein the specification (1310) of the first quality of service (DG1) takes place with regard to a bandwidth and/or a latency, and/or wherein the specification (1311) of the second quality of service (DG2) takes place with regard to a bandwidth and/or a latency. Method according to at least one of the preceding claims, further comprising: emulating (1320) the quality of service (DG; DG1, DG2) and/or the at least one variable (DG-CG) characterizing the quality of service by means of at least one counter (Z1; Z1-LAT, Z1-BB, Z2-LAT, Z2-BB), and/or using (1322) hardware-based management (VW-DG-HW) of the quality of service (DG) or of the quantity characterizing the quality of service (DG-CG). Method according to at least one of the preceding claims, further comprising at least one of the following elements: a) using (1330) at least one first counter (Z1-LAT) for a latency associated with a first peripheral component (208a), b) using (1331) a second counter (Z1-BB) for a bandwidth associated with the first peripheral component (208a), c) using (1332) at least one third counter (Z2-LAT) for a latency associated with a second peripheral component (208b), d) using ( 1333) of a fourth counter (Z2-BB) for a bandwidth associated with the second peripheral component (208b). Method according to at least one of Claims 5 until 6 , comprising: evaluating (1340) the at least one counter (Z1; Z1-LAT, Z1-BB, Z2-LAT, Z2-BB), for example by a software component (SW-K) and/or a hardware component (HW-K) , wherein, for example, the software component (SW-K) has a higher priority with regard to execution by the computing device (202) than at least one application (APP1), and, optionally, operating or continuing to operate (1342) the device (200) or at least an application (APP1) of the device (200) based on the at least one counter (Z1; Z1-LAT, Z1-BB, Z2-LAT, Z2-BB). Method according to at least one of Claims 5 until 7 , comprising: comparing (1350) a counter value (ZW1) of the at least one counter (Z1) with a comparison value (VW1), and, if the counter value (ZW1) is greater than the comparison value (VW1), signaling (1352), for example the exceeding the comparison value (VW1), to the at least one application (APP1) and/or a partition (PART1) associated with the at least one application (APP1). Device (200) for carrying out the method according to at least one of the preceding claims. Computer-readable storage medium (SM), comprising instructions (PRG) which, when executed by a computer (202), cause it to carry out the method according to at least one of the Claims 1 until 8th to execute. Computer program (PRG), comprising instructions that cause the execution of the program (PRG) by a computer (202) this, the method according to at least one of Claims 1 until 8th to execute. Disk signal (DCS) that the computer program (PRG) looks for claim 11 transmits and/or characterizes. Use of the method according to at least one of Claims 1 until 8th and/or the device (200). claim 9 and/or the computer-readable storage medium (SM). claim 10 and/or the computer program (PRG). claim 11 and/or the data carrier signal (DCS). claim 12 for at least one of the following elements: a) enabling a deterministic runtime behavior of at least some, preferably all, applications (APP1, APP2, APP3) of the device (200), b) avoiding a new homologation for a first application (APP1), in particular in the Changing at least one further application (APP2), c) deterministic separation of applications (APP1, APP2), for example with regard to access to the at least one peripheral component (208).

Images