System on chip with secure hardware subsystem

Abstract

The invention relates to a system on chip with a secure hardware subsystem. A system having one or more secure hardware subsystems is described herein. The system includes a data bus and a first subsystem. The first subsystem operates in a secure state and a normal state, which includes control logic. The first subsystem further comprises: at least one hardware module that generates a default output in a secure state and a non-default output in a normal state; a memory coupled to the bus interface, receiving the configuration data from the data bus, and storing the received configuration data; and a data verifier that verifies the configuration data when the first subsystem is in the secure state and signals to the control logic whether the configuration data is valid. The control logic transitions the first subsystem to a normal state in response to the data validator sending a signal to inform the configuration data to be valid, and the hardware module receives the validated data and uses it to generate a non-default output in response to the data validator sending a signal to inform the configuration data to be valid.

Description

Technical Field

[0001] The present disclosure relates generally to integrated circuits (ICs), and in particular to integrated circuits having a secure hardware subsystem designed to comply with certain requirements regarding functional safety. Background Art

[0002] Modern ICs can include large amounts of memory, multiple microprocessors or processor cores, and multiple peripherals that provide system-level functionality in a single IC. In other words, ICs can include more and more subsystems integrated on a chip that can perform different functions. Therefore, ICs are also called system-on-chip (SoC). These individual subsystems can be connected together via one or more buses. Therefore, modern ICs can provide more complex functionality than previous generations of ICs. Although this is beneficial to end users because these ICs provide additional functionality, however, as the number of subsystems increases, configuring these ICs at power-on becomes increasingly complex. This is especially true for safety-critical applications. For example, in many automotive systems, where the car carries human passengers and / or valuable cargo, errors caused by subsystem failures of the IC can be dangerous.

[0003] Taking into account that some subsystems of an IC may be more critical in terms of safety (and therefore be subject to higher safety requirements) than others, the inventors therefore set themselves the goal of improving the current concepts of IC design. Summary of the invention

[0004] The proposed object is achieved by the systems of claim 1 and claim 6 and by the methods of claim 13 and claim 15. The dependent claims cover various embodiments and further developments.

[0005] According to one embodiment, a system includes a data bus and (at least) a first subsystem having a bus interface coupled to the data bus. The first subsystem is operable in a secure state and in a normal state, and includes control logic configured to transition the first subsystem to the secure state in response to a configuration instruction. The first subsystem further includes: at least one hardware module configured to generate a default output in the secure state and a non-default output in the normal state; a memory coupled to the bus interface and configured to receive configuration data for the hardware module from the data bus and store the received configuration data; and a data validator configured to: when the first subsystem is in the secure state, verify the configuration data and send a signal to the control logic (26) to inform whether the configuration data is valid. The control logic is configured to: in response to the data validator sending a signal to inform that the configuration data is valid, transition the first subsystem to the normal state, and the hardware module is configured to: in response to the data validator sending a signal to inform that the configuration data is valid, receive the verified data and use it to generate a non-default output.

[0006] According to another embodiment, the system includes a data bus, a first subsystem and (at least) a second subsystem. The first subsystem includes a first bus interface coupled to the data bus and a key generator, the key generator being configured to generate a key and transmit the key across the data bus via the first bus interface. The second subsystem includes a second bus interface, a data encoder and a data source. The data encoder is used to receive data from the data source, encode the data using a key, and transmit the encoded data to the first subsystem across the data bus. The first subsystem further includes control logic and a memory, the memory being coupled to the bus interface and configured to receive the encoded data from the data bus and store the received data. The first subsystem further includes a data verifier, which is configured to decode and verify the received data stored in the memory using a key, and send a signal to the control logic to inform whether the received data has been successfully decoded and verified. In addition, the control logic is configured to transition the first subsystem to a secure state when the data verifier does not send a signal to inform that the received data has been successfully verified within a predetermined time span.

[0007] Other embodiments relate to methods for operating a system including one or more secure hardware subsystems. According to one embodiment, the method includes: transitioning a hardware subsystem of the system into a secure state in response to a configuration instruction; receiving configuration data via a bus interface; and verifying the received configuration data. When the configuration data has been successfully verified, the verified configuration data is fed to a hardware module of the hardware subsystem, and the hardware subsystem is transitioned into a normal state, wherein the hardware module generates a default output in the secure state and generates a non-default output in the normal state. The non-default output depends on the configuration data.

[0008] According to another embodiment, a method includes: generating a key in a first subsystem of a system; transmitting the key to a second subsystem of the system; and receiving encoded data from the second subsystem by the first subsystem, wherein the encoded data has been generated using the key in the second subsystem. The method further includes: verifying the received data using the key in the first subsystem; when the verification of the data has been successful and the first subsystem is in a normal state, generating a non-default output by a hardware module of the first subsystem using the verified data; and when no data is received and successfully verified for more than a predetermined time, transitioning the first subsystem into a secure state, wherein when the first subsystem is in the secure state, the hardware module of the first subsystem generates a default output. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The present invention may be better understood with reference to the following drawings and description. The components in the drawings are not necessarily drawn to scale; instead, emphasis is placed on illustrating the principles of the present invention. Additionally, in the drawings, like reference numerals designate corresponding parts. In the drawings:

[0010] Figure 1 An example of a system having a secure hardware subsystem in communication with another subsystem is illustrated.

[0011] Figure 2 It is a diagram that can be configured Figure 1 A flow chart of an example of a method for a secure hardware subsystem.

[0012] Figure 3 Another example of a system having a secure hardware subsystem is illustrated.

[0013] Figure 4 It's a picture. Figure 3 A flow chart of one example of a method for a secure hardware subsystem to receive and authenticate data from another subsystem. DETAILED DESCRIPTION

[0014] As mentioned above, the aspect of functional safety is critical in many applications using ICs. To quantify the level of risk, for example in automotive systems, the automotive industry uses the Automotive Safety Integrity Level (ASIL), which is a risk classification scheme defined by the ISO 26262 standard (Road vehicles - Functional safety). Similar standards exist in fields such as aviation and other industries.

[0015] ASIL is established by performing a risk analysis of potential hazards by looking at the severity, exposure, and controllability of the vehicle operation scenario. The safety goal for that hazard determines the ASIL requirement. The standard identifies four ASILs: ASIL A, ASIL B, ASIL C, and ASIL D. ASIL D specifies the highest integrity requirements for the product, while ASIL A specifies the lowest integrity requirements for the product. Hazards identified as Quality Management (QM) do not specify any safety requirements.

[0016] In general, the subsystems within a given IC of a semiconductor die are configured by programming data for the various modules, and more particularly by writing the configuration data to a register set of each subsystem over a data bus, such as an Advanced Peripheral Bus (APB) if an Advanced Microcontroller Bus Architecture (AMBA) is used. For example, the configuration data may be stored in a non-volatile memory, and when the IC is powered on, the configuration data may be retrieved from the non-volatile memory and written to the various subsystems. The configuration data may adjust thresholds or set points used by the various subsystems, or may define reactions that the subsystems perform when certain events are detected by the subsystems or other subsystems of the system.

[0017] In some cases, the integrated circuit may include sufficient non-volatile memory to store configuration data and other required content. However, the non-volatile memory and other circuit devices may be manufactured according to an ASIL level lower than that required for the entire IC / system, or may be integrated in a separate IC. For example, the non-volatile memory of the system may be designed according to QM standards (e.g., flash memory, but not radiation-resistant flash memory), while the data it includes may be used in other subsystems with a higher ASIL level. In order to ensure that the content of the configuration data is correct, various types of error detection and error correction are known per se (e.g., cyclic redundancy check (CRC), etc.).

[0018] CRC and other techniques for error detection and / or correction are used to allow identification of corrupted data or even correction of corrupted data in some cases (referred to as error correction codes (ECC)). However, these techniques only confirm the correctness of the data itself (verification), but do not confirm whether the data was actually written to the correct location within the system (authentication). Furthermore, these techniques do not automatically prevent correctly written data from being subsequently modified in an undesirable manner.

[0019] Figure 1 An example of a system having one or more safety hardware subsystems in communication with other circuit devices is illustrated, which may be designed according to an ASIL level that is more relaxed than the ASIL level of the safety subsystems. Figure 1The system can be (but does not have to be) a system on a chip (SoC), which means that the subsystems are integrated into one semiconductor die or one chip package (system in package (SiP)).

[0020] according to Figure 1 In the example of , the security hardware subsystem 20 includes a bus interface 21 and an optional instruction interface 25. Both the interface 21 and the interface 25 allow communication with other circuit devices (e.g., controller circuits, subsystems, other ICs, etc.). If the ARM architecture is used, the bus interface 21 can be, for example, an advanced peripheral bus (APB). For example, the instruction interface 25 can be a single data signal (e.g., a logic signal) or another communication interface (such as a serial peripheral interface (SPI)). However, it should be noted that many other types of suitable bus systems are known per se and are therefore not discussed further in this article. The instruction interface 25 is optional because instructions can also be received via the bus interface 21. The instruction interface 25 can also be implemented by a simple signal input that receives a logic signal. In this example, the instruction is represented by a defined logic level of the received signal.

[0021] Data (particularly configuration data) received via bus interface 21 (eg, from a controller circuit outside secure hardware subsystem 20) may be stored in memory 23 of secure hardware subsystem 20. Memory 23 may include, for example, a set of configuration registers in which configuration data is stored.

[0022] The secure hardware subsystem 20 further includes a control logic 26 and a data verifier 24 (also referred to as a configuration verifier). The data verifier 24 is configured to verify the data stored in the memory 23 (or at least some of the data received via the bus interface 21) and send a signal to the control logic 26 to inform whether the stored data is valid. In this context, "valid" may not only refer to the integrity of the data having been verified using known methods (such as parity bits, CRC, error detection codes (EDC) or error correction codes (ECC), etc.), but also refers to the data having been written to the correct destination (address). The concept of verifying stored data is known per se (e.g., from US2023 / 0135490 A1) and is therefore not discussed further herein. The control logic 26 may receive instructions via the instruction interface 25.

[0023] The security hardware subsystem 20 further includes one or more hardware modules 22, which include hardware (HW) functions 221 (circuits that perform specific desired functions) that generate outputs. The output of the hardware module 22 depends on whether the security hardware subsystem 20 is in a "safe operation" state (referred to as "safe state") or in a "normal operation" state (referred to as "normal state", also referred to as "task state"). The current state (safe operation or normal operation) is indicated by the control logic 26. In the safe state, each hardware module 22 generates a desired default value 222 as an output (default output). In the task state, the hardware module 22 can generate a (non-default) output value that depends on the configuration data stored in the memory 23 (verified). In the depicted example, the switching between the default output and the non-default output can be accomplished by a multiplexer 223 controlled by the controller logic 26. It should be noted that other circuit devices can be used to replace the multiplexer to achieve similar or substantially the same results.

[0024] refer to Figure 2 The depicted flowchart further explains Figure 1 More specifically, Figure 2 The flowchart illustrates how to configure Figure 1 An example of a method for a secure hardware subsystem.

[0025] Configuration instructions are received by control logic 26 via instruction interface 25 (or via bus interface 21 if no separate instruction interface is provided) (see Figure 2 Step S1) to start Figure 2 In response to receiving the configuration instruction, the control logic 26 may trigger the security operation ( Figure 2 In order to switch to the secure state, the control logic 26 drives the multiplexer 223 included in the hardware module 22 to output the default value 222. In addition, the control logic 26 unlocks the signal path between the memory 23 and the HW function 221 of the hardware module 22. It should be noted that if the secure hardware subsystem 20 is already in the secure state, no action is required in step S2.

[0026] In the next step ( Figure 2 In step S3), the configuration data is received via the bus interface 21 and stored in the memory 23. In response to receiving the configuration instruction, the control logic 26 can trigger the reception of the configuration data. Alternatively, the controller (outside the secure hardware subsystem) that sends the configuration instruction or other circuit devices outside the secure hardware subsystem 20 can trigger the reception of the configuration data. The configuration data can be received before, during or after the transition to the secure state. As discussed above (refer to Figure 1, data validator / configuration checker 24), and then verifies the received configuration data ( Figure 2 If the verification is positive (the configuration data is valid), the hardware module 22 is configured using the verified data (or part thereof) ( Figure 2 For example, the configuration data or data derived therefrom may be copied to one or more registers of the hardware function 222 via an unlocked signal path. This step S5 requires the secure hardware subsystem to be in a secure state, since the signal path between the memory 23 and the hardware module 22 is unlocked only in a secure state. It should be noted that Figure 1 The locking mechanism shown is only an example and various other known locking mechanisms may be used instead. However, it is important that safety-related parts of the configuration of the hardware module 22 cannot be modified during normal operation (in the mission state).

[0027] Once the hardware module 22 has accepted (and stored) the new / updated (and previously verified) configuration data, the control logic 26 may trigger a transition into the task state ( Figure 2 Step S6). Switching to the task state requires driving the multiplexer 223 to switch back to the non-default output and locking the signal path between the memory 23 and the hardware module 22 to disable modification of the configuration data stored in and used by the hardware function 221. As mentioned, the non-default output depends on the configuration data.

[0028] If the verification of the received configuration data fails (in step S4), the hardware module 22 does not accept and store the configuration data ( Figure 2 Step S7), or simply ignore the configuration data. In this case, the secure hardware module 20 continues to operate in a safe state. Another configuration process can be triggered by another configuration instruction.

[0029] The concept of a secure hardware subsystem allows for secure configuration of hardware modules residing in the secure hardware subsystem. In this context, secure configuration means the secure configuration of hardware modules (see Figure 1 The outputs provided by the hardware module 22) are in a defined state during configuration, and the outputs may not provide unpredictable values ​​or signal levels by design due to incorrect configuration data. The concepts described herein also allow the design and certification of safety hardware subsystems according to the desired ASIL level, while the rest of the chip can be designed for a lower safety integrity level. The certified safety hardware subsystem design can be reused in other chips / systems.

[0030] Figure 3 Another example of a system having a secure hardware subsystem in communication with another subsystem is shown. Figure 4As shown, the system 10 includes two (or more) secure hardware subsystems. The first secure hardware subsystem 30 includes a bus interface 31 for receiving data from another subsystem, a memory 33 for storing received data (particularly configuration data), a control logic 36, and one or more hardware modules 32. Similar to the previous example, if the ARM architecture is used, the bus interface 31 can be, for example, an advanced peripheral bus (APB). However, many other types of suitable bus systems are known per se. The memory 33 may include, for example, a configuration register set in which configuration data is stored.

[0031] The hardware module 32 can be used in the same manner as described above. Figure 1 and Figure 2 The module 22 discussed above is designed in substantially the same manner. It includes a configurable hardware function 321 that produces a non-default output, a default function 322 that produces a safe (predefined, e.g., constant) default output, and a multiplexer 323 that allows the control logic 36 to select the non-default output or the default output depending on the state (safe state or task state) of the safety hardware subsystem 30. The control logic 36 has the same functions as described above with reference to FIG. Figure 1 The logic circuit 26 in question has a very similar purpose and function.

[0032] Figure 1 The security hardware subsystem 20 and Figure 2 The difference between the security hardware subsystems 30 is basically the way in which the received data is verified. Figure 3 As shown, a data verifier 34 included in the secure hardware subsystem 30 uses a key generated by a key generator 34 for data verification. The key can be a sequence of numbers (e.g., a 32-bit word) stored in one or more registers of the data verifier 34. The sequence of numbers can represent a random (e.g., pseudo-random) number. Many different methods for generating pseudo-random numbers (e.g., linear feedback shift registers, LFSRs) are known per se and are therefore not discussed further herein. The key can include timing information (such as the local time of the scheduler). The timing information can be used to check whether the configuration (or other control data) is relevant to the operation of the subsystem or is out of date. The key can be updated for each data transmission via the bus interface 21, wherein the transmission can include a data frame / packet or a group of data frames / packets.

[0033] Similar to the reference above Figure 1 and Figure 2 In the previous example described, the transmission can be triggered by a command (a request command or a simple request). Figure 3In the existing example, the request is generated by the requester 35. The requester 35 can generate requests regularly (periodically or from time to time), for example, according to a schedule. In the existing example, the scheduler 38 enables the requester 35 to generate new requests according to a predefined plan (schedule). The concept of a scheduler and its function are known per se and are therefore not explained in more detail herein. For the embodiments discussed herein, the manner in which the data transmission is triggered is not important. Instead, the focus is on the data transmission itself and the verification of the received data. In another example, the scheduled request can open a time window for configuration updates in the first subsystem and trigger data transfer from the second subsystem to the first subsystem.

[0034] Before explaining data transmission in more detail, the source of the data is briefly discussed. In the depicted example, the system 10 includes another secure hardware subsystem 40, which includes (among other things) a data bus 41, a data encoder 42, and a data source 43, and the data bus 41 is coupled to the bus interface 31 of the subsystem 30 via one or more bus lines. The bus interface 41 can be of the same type as the bus interface 31.

[0035] The specific implementation of data source 43 is not important to the discussion of the embodiments. For example, data source 43 may include a sensor that periodically outputs measured sensor data. However, other embodiments may use different data sources (such as, for example, a communication interface, (volatile or non-volatile) memory, a processor, etc.).

[0036] Figure 4 A flow chart is shown, which illustrates Figure 3 An example of a method for a secure hardware subsystem to receive and verify data from another subsystem. For the present discussion, it is assumed that: when the secure hardware subsystem 30 operates in a task state, the hardware module 32 (see Figure 3 ) requires updated data (e.g., sensor data) from a data source 43 to operate reliably. If (for whatever reason) the subsystem 30 does not receive valid data from the data source 43 within a certain time, the subsystem will transition to a safe state.

[0037] Figure 4 The process shown in FIG. 1 is based on the requester 35 (see Figure 3 ) Generate a new request ( Figure 4 As mentioned above, the scheduler 38 may periodically issue a request. In response to the request, the key generator 37 will generate a new key ( Figure 4 The new key may overwrite the existing key, which is thus updated. Further, the key may be transmitted to the encoder 42 (eg, via the communication interfaces 21 and 41) in the other secure hardware subsystem 40. Figure 4The encoder 42 uses the updated key to encode the data currently provided by the data source 43 ( Figure 4 The encoded data is transmitted to the secure hardware subsystem 30. Therefore, the subsystem 30 receives the encoded data ( Figure 4 33), which is stored in the memory 33 (see Figure 3 ).

[0038] The received data is then verified by the data verifier 34, which uses the key (previously sent to the encoder 43) to decode / verify the data ( Figure 4 If the data verification is successful, the hardware module 32 will accept and use the received (and verified) data ( Figure 4 Step S35), and the operation of the security hardware subsystem 30 can continue in the task state ( Figure 4 Step 36), where the output of the hardware module 32 may depend on the received data.

[0039] If the verification fails, the hardware module 32 will not accept (and therefore not use) the received data ( Figure 4 For example, the control logic 36 will lock the signal path between the memory 33 and the hardware module 32, which can continue normal operation for a short period of time using existing (possibly outdated) data. However, if no valid data is received within the defined time, a timeout may occur and the control logic 36 may force the subsystem 30 to transition to a safe state ( Figure 4 In this case, the subsystem 30 will continue to operate in a safe state, wherein the hardware module 32 provides a default output, as described above with reference to Figures 1 to 3 Further described.

[0040] In view of the above discussion, it is obvious that once a valid signal is not received within a defined time span, the system inevitably transitions to a safe state (where all hardware modules 32 generate default outputs) in response to a timeout. A counter that counts backward (synchronized with a clock signal) can be used as a timer, which is set to a defined counter value at startup or restart, and sends a signal to inform the timeout when the counter value reaches 0. The timer can be started when the subsystem 3 is powered on and restarted when the newly received signal is successfully verified. Therefore, if the new data can be successfully verified before the timer has counted down to 0, the timeout will never occur. However, if the timer reaches 0, the subsystem 30 will transition to a safe state and remain in a safe state until the new data is successfully verified. The timer can be included in the control logic 36. Transitioning the subsystem to a safe state can be indicated to other parts of the system, such as to trigger remedial action.

[0041] There may be different reasons for unsuccessful verification of received data. First, the key or the corresponding encoded data may have been damaged during data transmission. Second, the subsystem 40 may be defective and therefore unable to respond to the updated key. Therefore, the subsystem 40 encodes the new data using an outdated key. Third, the key generator 37, the data verifier or the bus interface may be defective.

[0042] The encoding of the data (as performed by the encoder 42 of the subsystem 40) can be accomplished in various ways. For example, a hash value can be calculated from the concatenation of the data and the current key, and the hash value can be appended to the data. The data verifier 34 can perform the same operation and verify whether the calculated hash value matches the received hash value. Alternatively, a CRC value can be calculated based on the concatenation of the data and the current key. The technician will consider various other options depending on the requirements of the actual application.

[0043] Although the present invention has been illustrated and described with reference to one or more implementations, changes and / or modifications may be made to the illustrated examples without departing from the spirit and scope of the appended claims. In particular, with respect to the various functions performed by the above-described components or structures (units, components, devices, circuits, systems, etc.), unless otherwise indicated, terms used to describe such components (including references to "means") are intended to correspond to any component or structure that performs the specific function of the described component (e.g., functionally equivalent), even if not structurally equivalent to the disclosed structure, which performs the functions illustrated in the exemplary implementation of the invention herein.

Claims

1. A system comprising: Data bus; A first subsystem (20) having a bus interface (21) coupled to the data bus, wherein the first subsystem (20) is operable in a safe state and in a normal state, and comprises: control logic (26) configured to transition the first subsystem (20) into the safe state in response to a configuration instruction; at least one hardware module (22) configured to generate a default output in the secure state and a non-default output in the normal state; a memory (23) coupled to the bus interface (21) and configured to receive configuration data for the hardware module (22) from the data bus and to store the received configuration data; a data validator (24) configured to: when the first subsystem (20) is in the safe state, verify the configuration data and send a signal to the control logic (26) to inform whether the configuration data is valid, wherein the control logic (26) is configured to: in response to the data validator (24) sending a signal informing that the configuration data is valid, transition the first subsystem (20) to a normal state; and The hardware module (22) is configured to: in response to the data validator (24) sending a signal indicating that the configuration data is valid, receive the verified data and generate the non-default output using the verified data.

2. The system according to claim 1, The hardware module (22) is configured to not allow modification of the configuration data used to generate the non-default output in the normal state.

3. The system according to claim 1 or 2, The hardware module (22) is configured to generate the non-default output independently of the configuration data.

4. The system according to claim 1, Wherein the first subsystem comprises a command interface (25); and The command interface (25) is further configured to enable the control logic (26) to transition the first subsystem (20) to a safe state when receiving a configuration command via the command interface (25).

5. The system according to any one of claims 1 to 4, The control logic (26) is configured to prevent the hardware module (22) from allowing modification of the configuration data used to generate the non-default output in a normal state.

6. A system comprising: Data bus; a first subsystem (30) having a first bus interface (31) coupled to the data bus, wherein the first subsystem (30) includes a key generator (37) configured to generate a key and transmit the key across the data bus via the bus interface (21); a second subsystem (40) having a second bus interface (41), a data encoder (42), and a data source (43), wherein the data encoder (42) is used to receive data from the data source (43), encode the data using the key, and transmit the encoded data to the first subsystem (30) across the data bus; The first subsystem (30) further comprises: Control logic (36), a memory (33) coupled to the bus interface (31) and configured to receive the encoded data from the data bus and store the received data; a data verifier (34) configured to decode and verify the received data stored in the memory (33) using the key, and to send a signal to the control logic (36) to inform whether the received data has been successfully decoded and verified, and The control logic (36) is configured to transition the first subsystem (30) to a safe state when the data verifier (34) does not send a signal indicating that the received data has been successfully verified within a predetermined time span.

7. The integrated circuit according to claim 6, The key generator (37) of the first subsystem (30) is configured to generate and transmit a new key for each data frame of the data to be encoded and transmitted by the data encoder (42) of the second subsystem (40).

8. The system according to claim 7, The key is a random number.

9. The system according to any one of claims 6 to 8, wherein the first subsystem further comprises: The requester (35) is configured to periodically generate request instructions. The key generator (37) generates a new key in response to each request instruction.

10. The system according to any one of claims 6 to 8, wherein the first subsystem further comprises: At least one hardware module (32) is configured to generate a default output in a secure state and a non-default output in a normal state, wherein the non-default output depends on the data decoded and verified by the data verifier (34).

11. A system according to any one of claims 6 to 10, The control logic (36) is configured to prevent the hardware module (22) from generating a non-default output using data that has not been successfully validated.

12. The system according to any one of claims 1 to 11, The system is a system on chip or a system in package.

13. A method comprising: Transitioning a hardware subsystem (20) of the system (10) into a safe state in response to the configuration instruction; Receiving configuration data via the bus interface (21); verifying the received configuration data; When the configuration data has been successfully verified: feeding the verified configuration data to a hardware module (22) of the hardware subsystem (20), and transitioning the hardware subsystem (20) to a normal state, The hardware module (22) generates a default output in a safe state and generates a non-default output depending on the configuration data in a normal state.

14. The method according to claim 13, The hardware module does not allow modification of the configuration data used to generate the non-default output in the normal state.

15. A method comprising: Generating a key in a first subsystem (30) of the system (10); transmitting the key to a second subsystem (40) of the system (10); receiving encoded data from the second subsystem (40), wherein the encoded data has been generated in the second subsystem (40) using the key; verifying the received data using the key in the first subsystem (30); When the verification of the data has succeeded and the first subsystem (30) is in a normal state, generating a non-default output using the verified data by the hardware module (32) of the first subsystem (30); as well as When no data is received and successfully verified for more than a predetermined time, transitioning the first subsystem (30) to a safe state, Wherein when the first subsystem (30) is in the safe state, the hardware module (32) of the first subsystem (30) generates a default output.

16. The method according to claim 15, Wherein the first subsystem periodically generates and transmits a new key for the data to be encoded and transmitted by the second subsystem.

Images