SAFETY DEVICE AND METHOD FOR CONTINUOUS MONITORING OF THE FUNCTIONAL SAFETY OF A DIGITAL SIGNAL PROCESSOR

Abstract

Disclosed is an integrated circuit (100) comprising a specific digital signal processor (DSP) (111) with an associated arithmetic logic unit (ALU) (112), and a dedicated safety device (120) for continuously monitoring the functional safety of this specific digital signal processor (111). The digital signal processor (111) triggers a predetermined safety mechanism (121), which causes the ALU (112) to execute one or more predefined test operations. The test results obtained are stored in a test result register (130). At specific times, the safety device (120) reads the contents of the test result register (130) and compares the contents with a predefined correct test result. In case of a deviation, an error message is generated.

Description

TECHNICAL AREA

[0001] The present disclosure relates to a hardware-implemented integrated circuit comprising a single digital signal processor with an arithmetic logic unit, and a safety device for continuous monitoring of the functional safety of the digital signal processor. BACKGROUND

[0002] Technical systems, as well as automobiles, can cause significant material damage or pose risks to people or the environment if used improperly. Therefore, a risk and hazard analysis is conducted for these systems at the beginning of their design. The primary method for minimizing risk is the design of the systems through the application of product-specific guidelines and standards.

[0003] The residual hazards identified in the risk analysis must be mitigated by safety devices. During the risk analysis, these hazards are quantitatively assessed. The potential damage can range from minor, reversible injuries to the death of multiple people. The greater the potential damage and the higher the probability of a harmful event occurring, the higher the required safety level. Various risk assessment levels are listed in the application standards. In the process industry, the Safety Integrity Level (SIL) is most commonly used, ranging from SIL1 to SIL4 with increasing requirements.

[0004] In the automotive sector, the so-called ASIL (Automotive Safety Integrity Level) is used. ASIL is part of the ISO standard ISO 26262 ("Road vehicles - Functional safety") for safety-related electrical / electronic systems in motor vehicles. ISO 26262 defines a process model along with required activities and work products, as well as methods to be applied in development and production. It is also frequently referred to as 'functional safety'.

[0005] With the ever-increasing complexity of electronic components in vehicles, the risk of malfunctions also rises. If a safety-relevant component is affected by such a malfunction, in the worst-case scenario, people could be killed. For example, if a power steering control unit in a motor vehicle were to report an incorrect steering angle position while driving at high speed, this could lead to an accident. To minimize the risk of dangerous malfunctions in safety-relevant electronic systems in vehicles, it is advantageous if these systems are developed in accordance with relevant standards, such as the aforementioned ISO 26262. Users include automotive manufacturers, automotive suppliers, and testing institutes.

[0006] ISO 26262 focuses on safety in the sense of intrinsic safety (protecting the environment from the product), which is why it is also referred to as functional safety. Normal function can certainly be restricted or even deactivated for safety reasons (system response). It is not enough that the function is executed correctly; the development goal must also be to ensure that it is executed in the correct context and does not activate automatically in the wrong situation. For example, if the airbag deploys in an accident, its function is flawless. If, on the other hand, it deploys during normal driving, the function may be flawless, but in the wrong context, it could pose a functional safety problem. However, considering only the effect of the airbag, the consequences for the driver's head are the same in both cases.

[0007] A hazard analysis determines the safety requirement level, which is classified from ASIL A to ASIL D and requires additional development measures depending on the ASIL. In ISO 26262, this risk analysis is performed using a defined, qualitative methodology. If the risk is so low that application of the standard is not required, the hazard is assigned the ASIL QM classification. Otherwise, the QM classification or ASIL A to ASIL D can be determined for each hazard from a predefined table. The ASIL increases from A to D, and with it, the effort required by the methods specified in the standard and detailed in the respective parts also increases.

[0008] A suitable risk or hazard analysis can be created, for example, using an FMEDA (Failure Modes, Effects, and Diagnostic Analysis). This is a risk analysis method frequently used in safety-critical systems, particularly in the automotive and aerospace industries.

[0009] Safety-critical systems can be categorized, for example, using PMHF (Probabilistic Metric for Random Hardware Failures) according to the definitions of ISO 26262. The term "Probabilistic Metric for Random Hardware Failures" refers to a probabilistic metric used to measure or evaluate random hardware failures. PMHF describes quantitative criteria for the residual risk of a safety objective being violated by random hardware failures. In simpler terms, PMHF, as defined by ISO 26262, is a metric for representing the robustness of a safety architecture.

[0010] PMHF results are reported in FIT, or more precisely, using a FIT rate (FIT: Failures In Time). The FIT rate is a unit that describes the frequency of failures. 1 FIT corresponds to one failure per 1 billion (10^9) hours of operating time.

[0011] In the context of fault tolerance and reliability in complex systems, the term SPFM (Single Point Fault Metric) is also known, according to the definitions in ISO 26262. SPFM describes quantitative criteria for the effectiveness of the safety architecture with regard to handling single-point and residual faults. Simply put, SPFM describes a metric for the proportion of remaining dangerous faults relative to all faults. This is expressed as a percentage.

[0012] The Single Point Fault Metric (SPFM) refers to a metric that describes the risk or impact of a failure at a single point in a system, a so-called Single Point Fault (SPF). A Single Point Fault (SPF) is a failure that occurs at a single location in the system and can potentially affect the entire system. This means that a failure in a single part or component can jeopardize the functioning of the entire system or a part of it. The Single Point Fault Metric (SPFM) quantifies the risk or impact of a failure at a single point or component in a system.

[0013] The precise definitions of PMHF, PMHF-FIT rate, and SPFM can be found in ISO 26262. These same definitions also apply to this document.

[0014] When system failures occur, which are used to classify the resulting hazard into the different ASIL levels, a distinction is made between random and systematic failures. Random failures are hardware failures that occur statistically and with a reproducible probability in electronic components. The failure rates determined in functional safety can therefore only refer to random failures. The failure rates determined for random failures are based on operation under the permissible operating conditions.

[0015] The previously mentioned ASIL is used in the various parts of ISO 26262 to recommend measures. Particularly in Part 5 (Hardware) and Part 6 (Software), numerous tables with methods and recommendations can be found, which depend on the ASIL. For example, a deductive analysis such as FTA (Fault Tree Analysis) is only strongly recommended from ASIL C and ASIL D upwards.

[0016] In the automotive sector, the hardware is typically designed as dedicated control units, and the software is integrated as firmware running on the hardware. Individual vehicle components usually have their own control units, such as an airbag control unit, an ABS control unit, and so on. Since these control units usually perform very specific and specialized tasks, particular attention is paid during their design to efficient, i.e., fast and reliable, execution of each task. For this reason, control units typically use integrated circuits (e.g., ASICs: Application-Specific Integrated Circuits) with specialized digital signal processors (DSPs: Digital Signal Processors).

[0017] To meet the aforementioned safety-related requirements, such as those of ISO standard 26262, various approaches exist today. For example, two DSPs are integrated into a control unit to create fail-safe redundancy. However, this requires additional chip area in the corresponding integrated circuit, which increases costs. Furthermore, separate firmware must be developed for the second redundant DSP, which also leads to increased costs and greater complexity in the circuit design.

[0018] As an alternative to redundant hardware, standardized software-level backup mechanisms can be integrated, such as time-watch dogs or program counter parity checks (PC). However, these only detect an insufficient number (only about 10-15%) of error states, such as a total system failure ("no operation"), which in turn leads to an undesirably high PMHF FIT rate in the FMEDA.

[0019] Furthermore, existing security mechanisms completely disregard the actual computing unit, namely the arithmetic logic unit ALU (Arithmetic Logic Unit).

[0020] Therefore, it would be desirable to improve existing solutions for the functional safety of DSPs in such a way that errors (especially SPF: Single Point Failure) during runtime can be detected with a probability of over 90%, while simultaneously saving valuable chip area. SUMMARY

[0021] This can be achieved with a hardware-implemented integrated circuit (e.g. ASIC) as well as with a method having the features of the respective independent claims.

[0022] The innovative circuit includes a specific digital signal processor (DSP) with an associated arithmetic logic unit (ALU), and a dedicated safety device for continuously monitoring the functional safety of the DSP. The DSP is designed to repeatedly execute a predetermined safety mechanism. This mechanism instructs the ALU to perform one or more predefined test operations (opcodes), and the resulting test results are stored in an ALU check results register. The safety device is designed to read the contents of the ALU check results register at specific intervals, compare them to a predefined correct test result, and generate an error message if a discrepancy is detected.

[0023] This innovative method is used to monitor the functional safety of a specific digital signal processor (DSP) integrated into a circuit. The method is executed using a dedicated safety device and includes, among other things, the periodic execution of a built-in safety mechanism, preferably compliant with ISO 26262. This safety mechanism can, for example, cause one or more predefined test operations (opcodes) to be executed by an ALU integrated within the DSP, with the test result being stored in a test result register ("ALU-check-results-register"). The method also includes reading the contents of the test result register at predefined intervals and comparing the read contents with a predefined, correct test result.Furthermore, the procedure includes generating an error message in the event of a detected deviation between the specified correct test result and the content read from the test result register.

[0024] Furthermore, a computer program product for executing the method, as well as a corresponding storage medium, are the subject of the present disclosure, particularly when the method is executed on a computer.

[0025] The person skilled in the art will recognize, upon reading the following detailed description and upon looking at the accompanying drawings, further features and advantages of the invention, which are set out in particular in the dependent claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The present disclosure is illustrated by way of example and without limitation in the figures of the accompanying drawing, in which the same reference numerals refer to similar or identical elements. The elements in the drawings are not necessarily shown to scale. The features of the various examples shown can be combined, provided they are not mutually exclusive. Fig. Figure 1 shows a schematic block diagram of an exemplary embodiment of an innovative circuit with a safety device, Fig. Figure 2 shows a schematic block diagram of another embodiment of an innovative circuit with a safety device, Fig. Figure 3 shows a graph for the quantitative assessment of the frequency of calls to specific opcodes, and Fig.Figure 4 shows a schematic block diagram of an innovative process according to an exemplary embodiment. DETAILED DESCRIPTION

[0027] The embodiments described here enable the monitoring of the functional safety of a specific DSP (Digital Signal Processor) equipped with an ALU (Arithmetic Logic Unit), without the need for an additional redundant DSP. Specifically, the functional safety of the ALU can be monitored. For this purpose, an innovative, dedicated safety device is provided, which can be implemented as an additional hardware component and equipped with appropriate firmware. "Dedicated" means that this safety device is assigned to precisely this one specific DSP.

[0028] The safety device can instruct a specific DSP to trigger a safety mechanism (e.g., a state machine), which in turn can call various functions or execute operations. The safety mechanism might, for example, include a self-test function. The test results of the functions called or operations executed via the safety mechanism can be compared to a predefined target test result. If a deviation is detected, the safety device can issue an error message.

[0029] A DSP, along with its associated ALU, can be integrated, for example, into a hardware-implemented integrated circuit, such as an ASIC (Application-Specific Integrated Circuit). In this case, the DSP is the main block in the signal processing chain. Therefore, ISO 26262 identifies the DSP as the most critical architectural element with regard to functional safety.

[0030] To meet safety-related requirements, such as those of the aforementioned ISO 26262, various concepts exist today. For example, two DSPs are installed in a control unit to create fail-safe redundancy. However, the redundant DSP requires additional chip area in the corresponding integrated circuit, which increases costs. Furthermore, separate firmware must be developed for the second redundant DSP, which also leads to increased costs and greater complexity in the circuit design.

[0031] As an alternative to redundant hardware, standardized software-level backup mechanisms can be integrated, such as time-watch dogs or program counter parity checks. However, these only detect an insufficient number (only about 10-15%) of error states, such as a total system failure ("no operation"), which in turn leads to an undesirably high PMHF FIT rate in risk assessments (e.g., FMEDA).

[0032] Furthermore, existing security mechanisms completely disregard the actual computing unit, namely the arithmetic logic unit ALU (Arithmetic Logic Unit).

[0033] All these problems can be addressed with an innovative circuit (including DSP and ALU), whereby the specific DSP used has a dedicated safety device which in turn can execute a safety mechanism to verify the functional safety of the DSP, and especially the ALU.

[0034] Fig. Figure 1 shows a schematic block diagram of a first embodiment of an innovative hardware-implemented integrated circuit 100 with a first functional block 110, which includes, among other things, a DSP 111 and an ALU 112.

[0035] The DSP 111 is a specific, i.e., single, DSP responsible for executing a particular central chip function. As explained in more detail below, the circuit 100 innovatively features a dedicated safety device 120, which is specifically responsible for this one DSP 111 and its associated ALU 112. Of course, a circuit 100 or a control unit can contain other DSPs with corresponding ALUs (not explicitly shown here), in which case each specific DSP with ALU would have its own dedicated safety device. For the sake of simplicity, however, only a single specific DSP 111 with its associated dedicated safety device 120 will be described below as an example.

[0036] The in Fig.The safety device 120 shown in Figure 1 serves to continuously monitor the functional safety of this specific DSP 111, including the associated ALU 112. As illustrated here, the safety device 120 can, for example, include a digital comparator in its hardware. Alternatively or additionally, the safety device 120 can perform a time-out check or a window check. The time-out check verifies whether the test result is generated by the ALU 112 within a certain time. The window check verifies whether the test result is generated by the ALU 112 within a certain time window. The time-out check thus only detects timeouts, while the window check detects both timeouts and timeouts.

[0037] At a functional level, the safety device 120 includes a safety mechanism 121, which can be triggered by the DSP 111 and / or the ALU 112. The safety mechanism 121 can be triggered repeatedly, i.e., multiple times in succession.

[0038] Safety mechanism 121 serves to verify the aforementioned functional safety of the DSP 111 or the ALU 112. When safety mechanism 121 is triggered, one or more predefined operations (triggered by so-called opcodes) are executed by the ALU 112.

[0039] An opcode (operation code) is the part of a machine instruction that specifies which operation or action the CPU should perform. It is a central component of assembly language and the machine language of a processor. Opcodes are essential for low-level programming because they directly represent the instructions that control a processor's hardware.

[0040] Functions and characteristics of an opcode: 1. Operation: The opcode specifies the type of operation to be performed, e.g., addition, subtraction, multiplication, logical operations, data movement (e.g., loading or storing values), or control commands. 2. Machine language: Opcodes are typically encoded in binary form, with each CPU architecture having its own set of opcodes. For example, the opcode for addition might be different in one architecture than in another. 3. Instruction format: An instruction often consists of an opcode and operational data (operands) that specify the variables or memory locations to which the operation is applied. An example might look like this: ◯ Opcode: ADD ◯ Operands: R1, R2 (the registers to be added) 4. Instruction set: The entirety of opcodes that a processor understands is called the instruction set. This defines which operations the processor can perform. Examples of opcodes: • MOV: Moves data from one location to another. • ADD: Adds two values. • SUB: Subtracts one value from another. • JMP: Jumps to a different address in the program.

[0041] The security mechanism 121, which calls the opcodes, can, for example, be implemented as an automated test method that can be integrated into electronic systems or hardware components to verify their own functionality without external testing equipment. This allows a system to diagnose itself and ensure that it is functioning correctly.

[0042] The safety mechanism 121 according to the invention can be compatible with the requirements of ISO 26262. The safety mechanism 121 according to the invention represents a technical solution that is implemented by E / E functions or elements or by other technologies to detect and mitigate or tolerate faults, or to control or prevent failures in order to maintain the intended functionality or to achieve or maintain a safe state. The safety mechanism 121 according to the invention can be implemented within a vehicle-specific system to prevent fault conditions from leading to single-point faults and to prevent fault conditions from leading to latent faults.

[0043] The safety mechanism 121 according to the invention can be capable of bringing the vehicle-specific system into a safe state or maintaining it in that state. Alternatively or additionally, the safety mechanism 121 according to the invention can be capable of warning the driver so that he or she can control the effects of the fault, as defined in the concept of functional safety according to ISO 26262.

[0044] The main objectives of the safety mechanism 121 according to the invention are: • Early detection of errors: The system can detect errors during manufacturing, after commissioning, or during operation itself. • Ease of maintenance: Integrated self-tests allow systems to perform regular checks without the need for external test equipment or manual intervention. • Cost savings: Since external testing facilities are eliminated or reduced, overall costs can be lowered. • Reliability: Self-test functions can make systems more robust by indicating malfunctions at an early stage.

[0045] Examples of the application of safety mechanism 121: • Processors: In microprocessors, the safety mechanism 121 according to the invention can be used to test the correct function of the internal circuits. • Automotive industry: In modern cars, the safety mechanism 121 according to the invention can be used to monitor electronics such as sensors and control units.

[0046] The safety mechanism 121 according to the invention can be executed at regular intervals or on demand (e.g. when the system is started) to check its integrity and functionality.

[0047] The innovative safety mechanism 121 integrated into the safety device 120 can also be implemented in another form. As mentioned at the beginning, when the safety mechanism 121 is triggered, one or more predefined test operations (triggered by so-called opcodes) can be executed by the ALU 112.

[0048] The test results obtained can then be stored in a test result register 130. Test result register 130 can, for example, be a 16-bit register. The security device 120 can read the contents of test result register 130 at specific times. Test result register 130 can be cleared by the security device 120 during or after being read (so-called "clear-onread"). The test result read from test result register 130 can then be compared with a predefined correct test result. The correct test result corresponds to an expected positive test result. If the comparison between the actual test result and the predefined correct test result reveals a discrepancy, an error message 140 can be generated.

[0049] The specified correct test result may, for example, have been pre-calculated. It may be stored in a memory, such as a register. This memory may be structured, for example, as a lookup table. The previously mentioned comparison between an actually obtained test result and a correct test result stored in memory (e.g., a LUT) can be performed, for example, as a target-actual value comparison.

[0050] In one embodiment, it is possible to indicate that an error has occurred, but not which specific error occurred. In an alternative embodiment, an error description can also be displayed. In both cases, it is conceivable that a specific action, such as a chip reset, is executed after an error is detected.

[0051] The aim of the safety mechanism 121 according to the invention is to achieve a safe state. This can be achieved, for example, by transmitting an error message, by a chip reset, etc. The safety mechanism 121 according to the invention can thus ensure that a system in which the safety mechanism 121 is implemented does not enter a hazardous event.

[0052] In summary, for the in Fig.As shown in the embodiment 1, the DSP 111 can execute a specific function (e.g., a test function) at regular intervals, which contains one or more opcodes to be checked. The DSP 111 then stores the result of the called function in the test result register 130. The safety device 120 also compares the contents of register 130 at regular intervals with a potentially pre-calculated correct result and clears this register 130 when reading it. In case of a mismatch, an error message is generated, and optionally, a chip reset can be triggered.

[0053] In the cases described so far, the security mechanism 120 can involve the execution of a single operation or opcode. The test result stored in the test result register 130 contains the actual result of this single operation, and the specified correct test result can be a pre-calculated expected result of this single operation.

[0054] In an alternative embodiment, the security mechanism 121 can involve the execution of several individual operations. The test result stored in the test result register 130 could, in this case, contain the actual individual results of these multiple executed operations, with these actual results being stored in a compressed, readable code. This code could, for example, be a checksum such as a CRC code or a hash code.

[0055] In other words, an alternative design could involve storing a checksum, such as a CRC or hash code, of an executed sequence as the test result in register 130, instead of storing each individual test result. The comparison could then be performed using this compressed result. This alternative could lead to savings in chip area.

[0056] Fig. Figure 2 shows another possible embodiment. This embodiment is essentially similar to the one previously described with reference to Fig. In the discussed embodiment 1, we explain why elements with identical or similar functions are provided with the same reference numerals. To avoid repetition, please refer to the discussion above.

[0057] One difference is that here, the safety mechanism 121 involves the sequential execution of a series of operations (triggered by a sequence of opcodes). In this case, the safety device 120 can include a sequence counter.

[0058] This embodiment also allows for verification of the correct timing (sequence) of the successively called opcodes. The sequence counter can count and monitor whether the opcodes were executed in the correct chronological order.

[0059] The test result stored in test result register 130 can therefore contain the individual, sequentially listed, actual results of the sequence of executed operations. The sequence counter, in turn, can then count the individual operations called during the execution of the security mechanism and monitor their correct sequential execution by comparing the respective, sequentially listed, actual results of the individual operations with pre-stored expected results according to its current counter value; that is, each counter value can be assigned one expected result.

[0060] For example, the DSP 111 or the ALU 112 can execute certain sub-functions (e.g., test functions) at regular intervals, which contain the opcodes to be checked. The DSP 111 can then sequentially store the result of these functions in the test result register 130. The safety device 120 can then, also at regular intervals, compare the contents of the test result register 130 with the results that depend on the sequence counter. These target value results, in turn, may be pre-calculated and differ for different values ​​of the sequence counter. In the event of a discrepancy, an error message 140 can be generated, e.g., a chip reset is triggered. The advantage of this implementation is an increased diagnostic scope, since different instructions (opcodes) and / or different arguments (operands) can be monitored.

[0061] Table 1 below shows an exemplary overview of statement classes and associated operands. Table 1 Instruction class Input output Load Storage address Destination address, flags Save (Store) Source Register Storage address Branching Program counter address / increment (flags) Movement (Move / Jump) Source Register Destination address, flags Logical Mathematics Source Register Destination address, flags Immediate logic Constant, Register Registers, Flags Comparison R0, Source Register Destination address, flags

[0062] Table 1 shows eight working registers. Carry-zero flags and negative flags are also included. The instruction classes denote the operations to be performed, which are encoded with opcodes depending on the instruction set of the underlying microcontroller.

[0063] Fig.Figure 3 shows an example graph illustrating the purely qualitative frequency of calls to each opcode. The x-axis lists the respective opcodes. The y-axis represents (purely qualitative) the number of calls to each opcode. It can be seen, for example, that the movement instructions coded with the opcode "MOV" are called by far the most frequently, followed by the load instructions coded with the opcode "LD" and the jump instructions coded with the opcode "JMP".

[0064] Therefore, it makes sense for the innovative safety device 120 to test the most frequently used opcodes for checking the functional safety of the DSP 111 or the associated ALU 112.

[0065] According to one embodiment, the one or more predefined operations (opcodes) that the ALU 112 calls during the execution of the safety mechanism 121 can therefore include at least one LOAD instruction or one STORE instruction.

[0066] According to another embodiment, the one or more predefined operations (opcodes) that the ALU 112 calls during the execution of the safety mechanism 121 can include at least one instruction to perform an arithmetic calculation (e.g. ADD, SUB, MUL).

[0067] According to another embodiment, the one or more predefined operations (opcodes) that the ALU 112 calls during the execution of the safety mechanism 121 can include at least one JUMP instruction or one MOVE instruction.

[0068] Therefore, checking only a subset of the entire instruction set, i.e., a subset of all available opcodes, may be sufficient to test the functional safety of the DSP 111 or the associated ALU 112. This subset can include the most frequently called opcodes.

[0069] According to one conceivable embodiment, the safety device 120 can therefore be designed to execute the safety mechanism 121 using only a predetermined subset (e.g. less than 50%) of all operations (opcodes) present in the entire instruction set.

[0070] Even checking such a subset can be sufficient to detect more than a predefined number (e.g., more than 90%) of all randomly occurring hardware errors in the ALU 112. This is the so-called diagnostic coverage, which represents an important quality characteristic of the safety device 121 according to the invention.

[0071] In summary, it shows Fig. Figure 3 shows a non-limiting example of calculating the functional fault coverage for the proposed safety mechanism 121, based on a specific DSP algorithm. For example, the instruction calls with the highest call frequency can be included in the safety device 121 according to the invention to maximize the achievable diagnostic coverage. The diagnostic coverage is the sum of the frequencies of the observed instruction calls, measured against the total instruction calls of the firmware.

[0072] Another advantage of this innovation lies in its potential to save chip area. As in the Fig. 1 and Fig. As shown schematically in Figure 2, the safety device 120 can be implemented as a dedicated hardware block coupled to the DSP 111, and the safety mechanism 121, in turn, can be implemented as firmware integrated into the hardware block. This results in a significant saving of chip area compared to a second, fully redundant DSP. The development effort is also considerably lower.

[0073] Thus, this small hardware block is sufficient to implement the innovative security device 120 disclosed herein, which in turn can trigger the security mechanism 121 implemented therein. This eliminates the need for a second redundant DSP, resulting in a significant saving of valuable chip area. Compared to a redundant DSP, the innovative security device 120 requires a significantly reduced chip area, for example, only 5% to 10% of the chip area that would otherwise be needed by a redundant DSP. This allows for a saving of approximately 90% to 95% of the chip area compared to a redundant DSP.

[0074] Another important advantage arises from the way in which the innovative safety mechanism 121 can be implemented. According to one conceivable embodiment, the safety device 120 can include various implementations of the safety mechanism 121. This can be particularly advantageous for detecting and preventing systematic errors.

[0075] A diverse implementation refers to the concept of using multiple different implementations of a system, function, or algorithm to increase safety, reliability, or fault tolerance. This concept is frequently used in safety-critical applications and in software development.

[0076] Key features and benefits: 1. Redundancy: By using different implementations, potential sources of error can be eliminated or mitigated. If one implementation fails or is faulty, the others can continue to function correctly. 2. Fault tolerance: Various implementations can help minimize the impact of errors. This is particularly important in safety-critical sectors such as aviation, the automotive industry, and medical technology. 3. Security: In security-relevant systems, different implementations can protect against different attack vectors or failure scenarios. An attacker would have to overcome several different approaches to compromise the system. 4. Avoidance of Common-Mode Failures: The diversity of the implementations minimizes the risk of a common problem affecting all implementations (e.g., a flaw in the underlying logic or design). This also significantly reduces the probability of systematic errors in the DSP and in the safety device 120 and safety mechanism 121 according to the invention.

[0077] A diverse implementation is therefore an important strategy for improving the robustness and security of systems.

[0078] The following are purely exemplary, and not exhaustive, examples of different checks that can be carried out using the innovative safety device 120 to verify the functional safety of the DSP 111 or the associated ALU 112. (1) Memory operations and bus checks (implemented in hardware): • The safety device 120 should indicate an error if it detects the following: ◯ Bit flips on the address bus 1) or ▪ an incorrect type of access (read / write) 2) ▪ while the firmware part of the internal security mechanism 121 is running 3) .

[0079] Notes on the footnotes: 1) This can be achieved by providing two registers (used both for result verification and for providing inputs to the firmware part of security mechanism 121) at complementary addresses, so that accesses to these registers toggle all address bits. 2) This functional block expects the firmware part of the security mechanism 121 to implement a specific sequence of LOAD / STORE instructions, which it directly monitors by monitoring the memory bus of the DSP 111 (this does not correspond to the bitmap bus, which is intended to also detect errors in the address decoder of the bitmap). 3) This means that a fault should last at least as long as the execution time of the firmware part of security mechanism 121 in order to be reliably detected.

[0080] One such embodiment can therefore, for example, provide that the safety mechanism 121 includes the execution of a hardware-implemented check of memory access operations (e.g., Read / Write), whereby the memory bus is monitored to detect errors that occur in the address decoder.

[0081] In this case, the test result stored in test result register 130 contains the actually executed memory access operation stored on the memory bus, and the specified correct test result corresponds to an expected memory access operation.

[0082] The security device 120 can display an error if an incorrect memory access operation (e.g., read instead of write) is detected during the execution of the security mechanism 121.

[0083] The previously mentioned bit flips, which can be detected using two complementary registers, can in turn be part of a so-called "stuck-at" check. A stuck-at fault (also called a stuck-at error) originally refers to a term from digital circuit engineering. It describes a frequently occurring error in digital circuits, especially in integrated circuits (ICs) or hardware components.

[0084] In a stuck-at fault, a line or signal in the circuit behaves as if it always had a fixed value (either logic "0" or logic "1"), regardless of the input values ​​that would normally control the signal's value. This means that the affected line "gets stuck" and can no longer change to its intended state.

[0085] There are two main types of stuck-at errors: • Stuck-at-0 (SA0): The signal remains constant at "0", regardless of the inputs. • Stuck-at-1 (SA1): The signal remains constant at "1", regardless of the inputs.

[0086] A stuck-at fault can significantly impair the function of a digital circuit because the affected line no longer switches correctly between possible states, leading to faulty calculations or operations. For example, if one of the input lines in a logic gate (e.g., AND or OR) is always "0" due to a stuck-at fault (stuck-at-0), the gate cannot calculate the correct output.

[0087] To detect stuck-at errors, a test pattern creation is usually used, in which certain input combinations (tests) are used to check whether all lines in the circuit are functioning properly or whether they are erroneously stuck at a fixed value.

[0088] The innovative safety mechanism 120 achieves this by using two special registers located at complementary addresses. In the event of a stuck-at error of an address bit in one of the registers, the corresponding register can no longer be addressed. If the safety device 121 detects such a stuck-at error on the address bus, an error can be displayed. (2) Branch operation check - implemented in hardware:

[0089] The safety device 120 is intended to indicate an error if, during the execution of the firmware part of the safety mechanism 121, errors indirectly occur in branch operations due to missing or incorrect 1) Write accesses are detected.

[0090] Note on the footnotes: 1) Incorrectly executed branch instructions on the memory bus are expected to manifest either as completely missing write operations that are supposed to be performed at certain times, or as write operations with unexpected or incorrect data.

[0091] One such embodiment can therefore, for example, provide that the safety mechanism 121 includes the execution of a hardware-implemented check of jump and / or branch operations, whereby the memory bus is monitored to ensure that, after the execution of a jump or branch operation, the subsequent write operation takes place at the correct time and / or with the correct data.

[0092] The test result stored in test result register 130 includes the actual time and / or the actual data set of the subsequent write operation, and the specified correct test result includes an expected time and / or an expected data set of the subsequent write operation.

[0093] The safety device 120 can indicate an error if, after the jump or branch operation has been performed, the subsequent write operation was carried out at the wrong time and / or with incorrect data.

[0094] Another, more direct approach would be to examine the program counter (sequence counter) or the ROM address outputs. However, the lack of pipeline flush signals and the dual-ROM mode make it difficult to evaluate this information externally.

[0095] One such embodiment can therefore, for example, provide that the safety mechanism 121 includes the execution of a hardware-implemented check of jump and / or branch operations, whereby the internal program counter (PC: Program Counter or sequence counter) is evaluated for this purpose.

[0096] The test result stored in the test result register 130 contains the current address entry of the program counter, and the specified correct test result contains the expected target address of the jump or branch operation.

[0097] The safety device 120 can indicate an error if, after executing the jump or branch operation, the actual destination address displayed in the program counter does not match the expected destination address. (3) Register, logic, mathematics and comparison tests (implemented in hardware):

[0098] The safety device 120 is to indicate an error if, during the execution of the firmware part of the safety mechanism 121, it detects a mismatch between the delivered and the expected result of register, logic, math and comparison operations.

[0099] One such embodiment may therefore, for example, provide that the safety mechanism 121 includes the execution of a hardware-implemented check for the correct execution of at least one of the following operations: • a register access operation, • a logical operation, • an arithmetic operation, or • a comparative operation,

[0100] The test result stored in the test result register 130 contains the actual result of the respective operation performed, and the specified correct test result contains an expected result of this operation.

[0101] The safety device 120 can display an error if the actual test result stored in the test result register 130 does not match the expected test result. (4) Flag checks (implemented in hardware):

[0102] The security device 120 is to indicate an error if, during the execution of the firmware part of the security mechanism 121, it detects a mismatch between the provided and the expected flag vector (carry-zero flags and negative flags are also covered).

[0103] The security mechanism 121 loads at least one constant value from the bitmap and possibly other constant values ​​from the ROM, performs arithmetic summation, subtraction, multiplication and bit-shift operations on the loaded values ​​and stores the result in a special bitmap register. Note:

[0104] The MOVE SPECIAL and STORE instructions do not change flags. Therefore, the flags visible in the debugging register S0 can be moved to a working register and then written to a register of the DSP block for verification.

[0105] One such embodiment can therefore, for example, provide that the safety mechanism 121 includes the execution of a hardware-implemented check of status bits or status flags that are set by an operation called during the self-test function.

[0106] The test result stored in the test result register 130 contains the status bit or status flag actually set by this operation, and the specified correct test result contains a status bit or status flag expected by this operation.

[0107] The safety device 120 can indicate an error if the actually set status bit or status flag does not match the expected status bit or status flag.

[0108] The status bits or status flags can include at least one of the following flags: • a carry flag, • a zero flag, or • a negative flag. 5) Instruction set verification (implemented in firmware):

[0109] During instruction set verification, the security mechanism 121 loads at least one constant value from the register bank (e.g., bitmap) and possibly other constant values ​​from the ROM, performs arithmetic sum, subtraction, multiplication, and bit-shift operations on the loaded values, and stores the result in a special register bank entry.

[0110] One such embodiment can therefore, for example, provide that the security mechanism 121 includes a firmware-implemented check of the entire instruction set by loading constant values ​​from various sources (e.g., bitmap or ROM) and performing bitshift operations and / or arithmetic operations with these constant values.

[0111] The test result stored in the test result register 130 contains the actual result obtained of the respective operation performed, and the specified correct test result contains an expected result of the respective operation.

[0112] The safety device 120 can display an error if the actual result obtained does not match the expected result.

[0113] Another advantage of the innovative concept described herein is that the functional safety check of the DSP 111 or the ALU 112 can be carried out very quickly.

[0114] One embodiment might, for example, provide that the safety device 120 is configured to repeatedly read the contents of the test result register 130 and compare them with the predefined correct test result within a safety-critical time interval (t_safety) that is significantly shorter than a predefined error handling time interval. The safety-critical time interval (t_safety) describes the time between the occurrence of an error and reaching a safe state (e.g., transmission of an error message). The safety-critical time interval (t_safety) could, for example, be 2 ms or less.

[0115] The aforementioned predefined fault handling time interval, on the other hand, could be, for example, the Fault Handling Time Interval (FHTI) defined in the ISO 26262:2018 standard.

[0116] The term "Fault Handling Time Interval" (FHTI) refers to the period within which a fault or malfunction in a system should be detected, processed, and resolved. It is a defined timeframe within which corrective or treatment measures must be initiated after a problem or fault has occurred. The FHTI is therefore the combined timeframe of the fault detection time interval and the fault response time interval.

[0117] A short fault handling time interval means the system must react to errors within a narrow timeframe, while a longer interval may allow more leeway for error handling. The goal is always to minimize the impact of errors and maximize system availability.

[0118] The subject of the present disclosure is also a method for continuously monitoring the functional safety of a specific digital signal processor - DSP - 111, installed in an integrated circuit 100,

[0119] Fig. Figure 4 shows a schematic block diagram of a corresponding innovative procedure, which is carried out by means of a dedicated safety device 120 and includes the following steps: Block 401 includes the periodic execution of a built-in safety mechanism 121, wherein the safety mechanism 121 allows one or more predefined operations to be performed by an associated arithmetic logic unit - ALU - 112 integrated in the digital signal processor 111, and wherein test results obtained are stored in a test result register 130. Block 402 includes reading the contents of the test result register 130 at specified times and comparing the read contents with a specified correct test result. Block 403 includes generating an error message in case of a detected deviation between the specified correct test result and the content read from the test result register 130.

[0120] In summary, the present innovative concept describes an alternative approach for applications relevant to functional safety (mainly ASIL A and ASIL B, and to a limited extent also ASIL C and ASIL D) (e.g., electronic power steering, etc.) that only require a single DSP for executing the central chip functionality, which can be monitored by a small and diversely implemented additional circuit (= safety device).

[0121] Only one specific central DSP 111 is required, meaning that the use of one or more additional redundant DSPs, i.e., additional DSPs with identical or the same functionality or implementation as the central DSP, can be avoided.

[0122] This reduces the required chip area and complexity for monitoring the central DSP 111 to an absolute minimum, while simultaneously ensuring adequate diagnostic coverage. The concept provides online coverage in the application within a predefined safety timing (e.g., t_safety in FTTI or FHTI), particularly against single-point faults.

[0123] The innovative concept described herein can be applied, for example, in at least one of the following areas: • Automotive applications (ATV), • Windscreen wipers • electric power steering (ASIL D), • Motor commutation, • Electric powertrain, • Linear motion measurement, • Angle measurement • ABS and other driving safety-relevant applications

[0124] Summary and advantages of the innovative concept: • Only a single DSP 111 and the implementation of software / firmware are required to perform the main signal processing tasks, protocol generation, NVM data transmissions (NVM: Non-Volatile Memory), etc. • The innovative safety device 120 can be implemented in the form of a very simple, cost-efficient and small digital state machine with low complexity. • The innovative safety device 120 can be designed in the form of a diverse implementation with several different alternatives, for example to detect systematic errors. • With the aid of the innovative safety device 120, high diagnostic rates of over 90% are possible for monitoring a single DSP 111. This may be desirable to achieve target specifications for the single-point fault metric and the associated required FIT rates, e.g., for ASIL applications. • The innovative safety device 120 can be implemented as a digital state machine, and the verification of this digital state machine can be cheaper / more cost-optimized compared to a mixed-signal implementation. Furthermore, the innovative concept described herein can contribute to an increase in functional safety. • The innovative safety device 120 offers a very simple safety mechanism 121 for a specific single DSP 111, which provides cost-effective online coverage and avoids the complexity of additional DSPs (e.g., lock-step approach). • The innovative security device 120 is completely transparent to the end customer. They do not need to implement an external security mechanism for a DSP that requires documentation in a security manual. • The innovative safety device 120 can be used for cost-effective monitoring of a single DSP for functional safety applications in the automotive industry. • High diagnostic rate: The innovative safety device 120 detects a high number (50% to 60%, sometimes up to 90%) of randomly occurring hardware failures of the ALU 112 in the DSP 111. • Rapid diagnosis: The innovative safety device 120 executes the safety mechanism 121 at a high repetition rate, below predefined limit values ​​t safety lies, e.g. t safety < 2 ms • The innovative safety device 120 can (using firmware implementations of the safety mechanism 121) perform arithmetic calculations (e.g., additions, multiplications, subtractions, and shift operations) with constant input values ​​and store the results in a dedicated bitmap section (test result register 130); this can also include LOAD, STORE, MOVE, and JUMP instructions. • The innovative safety device 120 is designed as a separate and independent digital hardware block that reads the results and compares them with expected values; in case of an error, an error message can be generated. Alternatively or additionally, a chip reset and / or a reset of the digital section (e.g., including the DSP 111) can be performed.

[0125] It should be noted that the description and drawings merely illustrate the principles of the proposed methods and devices. A person skilled in the art will be able to implement various arrangements which, although not explicitly described or shown here, embody the principles of the invention and are included within its scope. Furthermore, all examples and embodiments outlined in this document are, in principle and expressly, intended only for explanatory purposes to help the reader understand the principles of the proposed methods and devices. Moreover, all statements in this document that describe principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to include their equivalents. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited non-patent literature

[0000] ISO 26262:2018

[0115]

Claims

Hardware-implemented integrated circuit (100) comprising: a specific digital signal processor - DSP - (111) with an associated arithmetic logic unit - ALU - (112), and a dedicated safety device (120) for continuously monitoring the functional safety of this specific digital signal processor (111), wherein the digital signal processor (111) is configured to repeatedly trigger a predetermined safety mechanism (121), wherein the safety mechanism (121) causes the ALU (112) to perform one or more predetermined test operations, and wherein test results obtained are stored in a test result register (130), and wherein the safety device (120) is configured to read the contents of the test result register (130) at specific times and compare them with a predetermined correct test result, and generate an error message in case of a deviation. Integrated circuit (100) according to claim 1, wherein the specified correct test result is pre-calculated and stored in a memory. Integrated circuit according to claim 1 or 2, wherein the specified correct test result is stored in a register bank. Integrated circuit (100) according to one of the preceding claims, wherein the safety device (120) is designed in the form of a hardware block coupled to the digital signal processor (111), and wherein the safety mechanism (121) is implemented in the form of firmware integrated in the hardware block. Integrated circuit (100) according to one of the preceding claims, wherein the safety device (120) includes a different implementation of the safety mechanism (121). Integrated circuit (100) according to one of the preceding claims, wherein the safety mechanism (120) includes the execution of a single operation, wherein the test result stored in the test result register (130) includes the actual result of this single operation, and wherein the predetermined correct test result includes a pre-calculated expected result of this operation. Integrated circuit (100) according to one of the preceding claims, wherein the safety mechanism (121) includes the execution of several individual operations, and wherein the test result stored in the test result register (130) includes the actual results of these executed operations, wherein these actual results are stored in a compressed, readable code. Integrated circuit (100) according to claim 7, wherein the readable code is a checksum, such as a CRC code or a hash code. Integrated circuit (100) according to one of the preceding claims, wherein the safety device (120) is configured to delete the test result register (130) during or after a successful readout, so that a new test result can subsequently be stored in it. Integrated circuit (100) according to one of the preceding claims, wherein the safety mechanism (121) includes a sequential execution of a sequence of operations, wherein the test result stored in the test result register (130) includes the individual, sequentially listed, actual results of the sequence of operations, and wherein the safety device (120) has a sequence counter configured to count the individual operations performed and to monitor their correct sequential execution. Integrated circuit (100) according to claim 10, wherein the sequence counter is configured to monitor the correct sequential execution by comparing the respective, sequentially listed, actual results of the individual operations with pre-stored expected results according to its current counter value. Integrated circuit (100) according to one of the preceding claims, wherein the one or more predefined operations which the ALU (112) performs include at least one instruction to perform an arithmetic calculation (e.g. ADD, SUB, MUL). Integrated circuit (100) according to one of the preceding claims, wherein the one or more predefined operations which the ALU (112) performs include at least one LOAD instruction or one STORE instruction. Integrated circuit according to one of the preceding claims, wherein the one or more predefined operations performed by the ALU (112) include at least one JUMP instruction or one MOVE instruction. Integrated circuit (100) according to one of the preceding claims, wherein the safety mechanism (121) includes the execution of a hardware-implemented check of memory access operations (e.g., read / write), wherein the memory bus is monitored to detect errors occurring in the address decoder, wherein the test result stored in the test result register (130) includes the actually executed memory access operation stored on the memory bus, wherein the specified correct test result is an expected memory access operation, and wherein the safety device (120) is configured to indicate an error if an incorrect memory access operation (e.g., read instead of write) is detected during the execution of the safety mechanism (121). Integrated circuit (100) according to one of the preceding claims, wherein the safety mechanism (121) includes the execution of a hardware-implemented stuck-at check on the address bus by using two special registers located at complementary addresses, wherein in the event of a stuck-at error of an address bit in one of the registers the corresponding register can no longer be addressed, and wherein the safety device (120) is configured to indicate an error when a stuck-at error is detected on the address bus. Integrated circuit (100) according to one of the preceding claims, wherein the safety mechanism (121) includes the execution of a hardware-implemented check of jump and / or branch operations, wherein the memory bus is monitored to determine whether, after the execution of a jump or branch operation, the subsequent write operation is performed at the correct time and / or with the correct data, wherein the test result stored in the test result register (130) includes the actual time and / or the actual data record of the subsequent write operation, wherein the predetermined correct test result includes an expected time and / or an expected data record of the subsequent write operation, and wherein the safety device (120) is configured to indicate an error if, after the execution of the jump or branch operation, the following occurs:The branching operation resulted in the subsequent write operation occurring at the wrong time and / or with incorrect data. Integrated circuit (100) according to one of claims 1 to 16, wherein the safety mechanism (121) includes the execution of a hardware-implemented check of jump and / or branch operations, wherein the internal program counter is evaluated for this purpose, wherein the test result stored in the test result register (130) includes the current address entry of the program counter, wherein the specified correct test result includes the expected target address of the jump or branch operation, and wherein the safety device (120) is configured to indicate an error if, after execution of the jump or branch operation, the actual target address displayed in the program counter does not match the expected target address. Integrated circuit (100) according to one of the preceding claims, wherein the safety mechanism (121) includes the execution of a hardware-implemented check for correct execution of at least one of the following operations: • a register access operation, • a logical operation, • an arithmetic operation, or • a comparison operation, wherein the test result stored in the test result register (130) includes the actual result of the respective operation performed, wherein the specified correct test result includes an expected result of this operation, and wherein the safety device (120) is configured to indicate an error if the actual test result stored in the test result register (130) does not match the expected test result. Integrated circuit (100) according to one of the preceding claims, wherein the safety mechanism (121) includes the execution of a hardware-implemented check of status bits set by a called operation, wherein the test result stored in the test result register (130) includes the status bit actually set by this operation, wherein the specified correct test result includes a status bit expected by this operation, and wherein the safety device (120) is configured to indicate an error if the status bit actually set does not match the expected status bit. Integrated circuit (100) according to claim 20, wherein the status bits comprise at least one of the following flags: • a carry flag, • a zero flag, or • a negative flag. Integrated circuit (100) according to one of the preceding claims, wherein the safety mechanism (121) includes a firmware-implemented check of the entire instruction set by loading constant values ​​from various sources (e.g., bitmap or ROM), and wherein bit-shift operations and / or arithmetic operations are performed with these constant values, wherein the test result stored in the test result register (130) includes the actual result obtained of the respective operation performed, wherein the specified correct test result includes an expected result of the respective operation, and wherein the safety device (120) is configured to indicate an error if the actual result obtained does not match the expected result. Integrated circuit (100) according to one of the preceding claims, wherein the safety device (120) is configured to execute the safety mechanism (121) using only a predetermined subset of all operations available in the entire instruction set. Integrated circuit (100) according to claim 23, wherein the safety device (120) is configured to detect more than a predefined number of randomly occurring hardware errors in the ALU (112) by means of the predetermined subset of operations. Integrated circuit (100) according to one of the preceding claims, wherein the safety device is configured to repeat the reading of the contents of the test result register and the comparison with the specified correct test result in a safety-critical time interval (tsafety) that is significantly shorter than a predefined fault handling time interval. Integrated circuit according to claim 25, wherein the predefined fault handling time interval is the Fault Handling Time Interval (FHTI) defined in the ISO 26262:2018 standard. Method for continuously monitoring the functional safety of a specific digital signal processor (DSP) (111) integrated into an integrated circuit (100), wherein the method is executed by means of a dedicated safety device (120) and comprises the following steps: periodic execution of a built-in safety mechanism (121), wherein the safety mechanism (121) causes one or more predefined test operations to be performed by an associated arithmetic logic unit (ALU) (112) integrated into the digital signal processor (111), and wherein the test results obtained are stored in a test result register (130); reading the contents of the test result register (130) at predefined times and comparing the read contents with a predefined correct test result.and generating an error message in the event of a detected deviation between the specified correct test result and the content read from the test result register (130). Computer program with program code for carrying out the method according to claim 27, when the program runs on a computer.

Images