A Method for Function Safety Monitoring of the Controller Level 2 Layer Incorporating Information Security

Abstract

The present invention discloses a method for monitoring the functional safety of the controller Level2 layer integrated with information security. By dividing a complete task into multiple functional modules and making Level1 and Level2 run in different cores; directly using plaintext data as input at the Level1 layer, and using plaintext plus MAC as input at the Level2 layer. Due to the latency brought by message authentication at the Level2 layer, there is asynchrony between Level1 and Level2 when executing the same functional program; and a timing mechanism is introduced when using the HSM module for message authentication to prevent the HSM from experiencing a stagnation problem; in addition, a shared storage area is established to store the intermediate results of the execution of the functional modules at the Level1 layer; the system log is recorded to restore the security state of the system in case of a failure. The present invention solves the problem of common cause failure, can ensure that the message comes from the correct sender and has not been tampered with midway, and prevents the latency problem caused by the stagnation of the HSM.

Description

Technical Field

[0001] The present invention relates to the technical field of controller EGAS monitoring architecture, and particularly to a method for monitoring the function safety of the Level 2 layer of a controller integrating information security. Background Art

[0002] The failures of an electronic and electrical system include both systematic failures caused by software and hardware design errors and failures caused by random hardware faults. According to the system architecture, various safety mechanisms need to be designed to prevent and detect functional failures, and be able to avoid or reduce the occurrence of hazards when a failure occurs. This requires a robust function safety software architecture to manage and control these safety mechanisms and reduce the overall development difficulty of function safety. Currently, EGAS is one of the most widely used safety architecture solutions. Among them, the designs of Level 1 and Level 2 are crucial.

[0003] In the current design, in order to maintain the independence of Level 1 and Level 2 and avoid common cause failures, redundant operations are often adopted. For example, two non-homogeneous redundant sensors will be designed to implement information collection and processing, or redundant software logic is used to monitor the basic functions of Level 1. However, these designs do not consider the asynchrony of program execution between the Level 1 layer and the Level 2 layer. When facing instantaneous electromagnetic interference, short-term power fluctuations, etc., these redundant designs may fail simultaneously, resulting in incorrect data collection or control commands. In addition, in terms of data transmission security, generally during the design processes of Level 1 and Level 2, whether the data transmitted from other controllers is maliciously damaged is not considered. Although some information security means can be used, such as message authentication mechanisms for verifying data integrity, directly adopting a message authentication mechanism for input data will cause operations related to authentication in the Level 1 layer, increasing time consumption and affecting real-time performance. Moreover, when performing message authentication, the HSM module may experience a stagnation problem. Summary of the Invention

[0004] The purpose of the present invention is to provide a method for monitoring the function safety of the Level 2 layer of a controller integrating information security, which can solve the technical problems mentioned in the background art.

[0005] The terms involved in the present invention are explained as follows:

[0006] EGAS: The EGAS three-layer monitoring concept was jointly proposed by several German automobile OEMs, and corresponding guiding documents were formulated. This monitoring concept was initially abstracted from the engine control system, which divides the engine control system into three levels: the Level 1 function layer, the Level 2 function monitoring layer, and the Level 3 controller monitoring layer.

[0007] HSM: Hardware Security Module, which is a computer device used to protect and manage keys and sensitive data used in strong authentication systems and simultaneously provide relevant cryptographic operations.

[0008] MAC: Message Authentication Code, which is a small piece of information generated after a specific algorithm and is used to ensure that a message comes from the correct sender and has not been tampered with in transit.

[0009] A method for monitoring the functional safety of the Level 2 layer of a controller integrating information security, which divides a complete task into multiple functional modules and makes Level 1 and Level 2 run in different cores; at the Level 1 layer, plaintext data is directly used as input, and at the Level 2 layer, plaintext plus MAC is used as input. Due to the latency brought by message authentication at the Level 2 layer, there is asynchrony between Level 1 and Level 2 when executing the same functional program; in addition, a shared storage area is established to store the intermediate results of the execution of the functional modules at the Level 1 layer, reducing the communication latency between core0 and core1; system logs are recorded to be able to restore the secure state of the system in case of a failure.

[0010] As a further technical solution of the present invention, the initialization of the system includes the following steps:

[0011] Step 1.1: When the system is initialized, the task is divided into 4 functional modules, including functional modules A, B, C, and D;

[0012] Step 1.2: Create a shared storage area and initialize blocks for each functional module for core0 and core1 to use;

[0013] Step 1.3: The system initializes and starts the logging mechanism simultaneously. The system log records include the status, intermediate results, and key information of core0 and core1 during the execution of each functional module, providing support for state rollback.

[0014] As a further technical solution of the present invention, the execution process of core0 includes:

[0015] Step 2.1: Transmit the communication data from other controllers to core0 in plaintext as the input signal of the Level 1 layer;

[0016] Step 2.2: The Level 1 layer starts to execute functional module A in the task;

[0017] Step 2.2.1: After the program execution of Function A module ends, core0 stores the intermediate result of Function A module into the corresponding block in the shared storage area;

[0018] Step 2.2.2: Update the system log to record the status at this moment;

[0019] Step 2.3: In the same way as the execution steps of Function A module, execute Function B, C, and D modules in sequence. After each function module is completed, store the intermediate result into the shared storage area and update the system log;

[0020] Step 2.4: After this task execution ends, core0 will continue to execute the next task.

[0021] As a further technical solution of the present invention, the execution process of core1 includes:

[0022] Step 3.1: Core1 is used for Level2 layer. First, it receives data in the form of plaintext plus MAC as the input of Level2 layer;

[0023] Step 3.2: Then, Level2 layer performs message authentication on the input data with the help of the HSM module, and core1 sends a message authentication request to the HSM core through an interrupt;

[0024] Step 3.3: At the same time, core1 starts the timer to time;

[0025] Step 3.4: The HSM core performs an interrupt response according to its own status. If the HSM core has no task to process at this time, it will give feedback to core1 through the interrupt response;

[0026] Step 3.5: After core1 receives the interrupt response, it sends the data to be processed to the HSM core;

[0027] Step 3.6: The HSM core performs integrity verification on the received data. The encryption engine inside the HSM core uses the key pre-stored in its secure storage area to calculate the plaintext data according to the CMAC / HMAC algorithm to obtain a new MAC value;

[0028] Step 3.7: Verify the calculated MAC value with the received MAC value. During this process, core1 continuously detects the time of the timer;

[0029] Step 3.8: If the timer time does not exceed the threshold and the verification fails:

[0030] Step 3.8.1: The HSM core sends a failure command to core1 through an interrupt;

[0031] Step 3.8.2: Core1 sends a severe error warning signal to the driver through the communication interface connected to the driver display device;

[0032] Step 3.8.3: The system enters the safe state, and core1 interrupts to boot the system into the fallback process;

[0033] Step 3.8.4: Read the system log, and roll back core0 and core1 to the previous loop state, that is, the state after executing a round of complete functional modules;

[0034] Step 3.8.5: Then, enter the fault handling mechanism, and adopt the same handling method as when there is a large difference in the difference during the function execution stage, limit the power output of the motor, and lower the vehicle speed;

[0035] Step 3.9: If the timer time exceeds the threshold, Layer 2 will directly skip the message authentication, and the system sends a warning signal such as an indicator light to the driver to prompt the driver that there may be a data security problem;

[0036] Step 3.10: If the verification in Step 3.8 is successful or Step 3.9 is executed, update the system log, and Layer 2 continues to execute tasks backward;

[0037] Step 3.11: Layer 2 starts to execute Function A module:

[0038] Step 3.11.1: After the program execution of Function A module ends, core1 reads the intermediate result of Function A module executed by Layer 1 in the shared storage area and compares the data of the same function processed by Layer 2;

[0039] Step 3.11.2: If the difference between the two is large, indicating a problem, core1 will send an interrupt request to the relevant interrupt handling module;

[0040] Step 3.11.3: The system responds to the interrupt and uses the system log to roll back core0 and core1 to the previous loop state;

[0041] Step 3.11.4: Then, enter the fault handling mechanism, and perform gradient limitation according to the size of the difference. When the difference is small but exceeds the normal fluctuation range, the system takes a limit response at this time; when the difference is large, at this time, in addition to the limit response, the system may further lower the vehicle speed; when the difference exceeds the maximum tolerance threshold, the system will enforce an emergency stop and cut off the connection with the power system;

[0042] Step 3.11.5: If the data comparison in Step 3.12 is normal, the system log is updated, and Layer 2 will continue to execute the task process backward;

[0043] Step 3.12: Similar to the execution of Function A module, successively execute Function B, C, and D modules. Each time a function module finishes execution, it will obtain the intermediate result of the corresponding function module from the shared storage area and compare it. Based on the data difference, it will determine whether to continue executing the task and update the system log or the system will enter a safe state;

[0044] When this task finishes execution, core1 will continue to execute the next task.

[0045] Beneficial effects achieved by the present invention:

[0046] Taking into account the asynchrony of program execution, the present invention divides a complete task into multiple function modules, creates a time difference between Level1 and Level2, and enables programs with the same function to be executed in different cores and at different time periods, thus solving the problem of common cause failure.

[0047] For the input data, the present invention uses a message authentication mechanism. Authentication is not considered at Level1, and message authentication is performed with the help of the HSM module at Level2, which can ensure that the message comes from the correct sender and has not been tampered with midway. At the same time, by introducing a timer mechanism for message authentication, if the authentication times out, Level2 will directly skip message authentication and send a warning signal to the driver, preventing the delay problem caused by the stagnation of the HSM. Description of the drawings

[0048] Figure 1 It is a schematic flowchart of the function safety monitoring method for the Level2 layer of a controller integrating information security according to the present invention.

[0049] Figure 2 It is a structural block diagram of the function safety monitoring method for the Level2 layer of a controller integrating information security according to the present invention. Detailed implementation manners

[0050] The technical solutions of the present invention will be introduced and described in detail below in conjunction with specific drawings.

[0051] As Figure 1-2As shown in the figure, a method for monitoring the functional safety of the Level 2 layer of a controller integrating information security divides a complete task into multiple functional modules and makes Level 1 and Level 2 run in different cores. At the Level 1 layer, plaintext data is directly used as input, and at the Level 2 layer, plaintext plus MAC is used as input. Due to the latency brought by message authentication at the Level 2 layer, there is asynchrony between Level 1 and Level 2 when executing the same functional program. In addition, a shared storage area is established to store the intermediate results of the execution of the functional modules at the Level 1 layer, reducing the communication latency between core0 and core1. The system log is recorded to be able to restore the security state of the system in case of a failure.

[0052] In this embodiment, during the initialization of the system, the following steps are included:

[0053] Step 1.1: When the system is initialized, the task is divided into 4 functional modules, including functional modules A, B, C, and D;

[0054] Step 1.2: Create a shared storage area and initialize blocks for each functional module for core0 and core1 to use;

[0055] Step 1.3: The system initializes and starts the logging mechanism simultaneously. The system log records the status, intermediate results, and key information of core0 and core1 during the execution of each functional module, providing support for state rollback.

[0056] In this embodiment, the execution process of core0 includes:

[0057] Step 2.1: Transmit the communication data from other controllers to core0 in plaintext as the input signal of the Level 1 layer;

[0058] Step 2.2: The Level 1 layer starts to execute functional module A in the task;

[0059] Step 2.2.1: After the program execution of functional module A ends, core0 stores the intermediate result of functional module A in the corresponding block of the shared storage area;

[0060] Step 2.2.2: Update the system log and record the status at this moment;

[0061] Step 2.3: In the same way as the execution steps of functional module A, execute functional modules B, C, and D in sequence. After each functional module is completed, store the intermediate result in the shared storage area and update the system log;

[0062] Step 2.4: After the execution of this task ends, core0 will continue to execute the next task.

[0063] In this embodiment, the execution process of core1 includes:

[0064] Step 3.1: Core1 is used for the Level2 layer. First, it receives data in the form of plaintext plus MAC as the input of the Level2 layer.

[0065] Step 3.2: Next, the Level2 layer performs message authentication on the input data with the help of the HSM module. Core1 sends a message authentication request to the HSM core through an interrupt.

[0066] Step 3.3: At the same time, core1 starts the timer to count.

[0067] Step 3.4: The HSM core performs an interrupt response according to its own state. If the HSM core has no task to process at this time, it gives feedback to core1 through the interrupt response.

[0068] Step 3.5: After receiving the interrupt response, core1 sends the data to be processed to the HSM core.

[0069] Step 3.6: The HSM core performs integrity verification on the received data. The encryption engine inside the HSM core uses the key pre-stored in its secure storage area to calculate the plaintext data according to the CMAC / HMAC algorithm to obtain a new MAC value.

[0070] Step 3.7: Verify the calculated MAC value with the received MAC value. During this process, core1 continuously detects the time of the timer.

[0071] Step 3.8: If the timer time does not exceed the threshold and the verification fails:

[0072] Step 3.8.1: The HSM core sends a failure command to core1 through an interrupt.

[0073] Step 3.8.2: Core1 sends a serious error warning signal to the driver through the communication interface connected to the driver display device.

[0074] Step 3.8.3: The system enters the safe state, and core1 guides the system into the fallback process through an interrupt.

[0075] Step 3.8.4: Read the system log, and roll back core0 and core1 to the previous loop state, that is, the state after executing a round of complete functional modules (such as functions A, B, C, D).

[0076] Step 3.8.5: Then, enter the fault handling mechanism, and adopt the same handling method as when there is a large difference anomaly during the function execution stage, limit the power output of the motor, and reduce the vehicle speed.

[0077] Step 3.9: If the timer time exceeds the threshold, Level2 will directly skip message authentication, and the system will send warning signals such as indicator lights to the driver, indicating that there may be data security issues;

[0078] Step 3.10: If the verification in Step 3.8 is successful or Step 3.9 is executed, update the system log, and Level2 will continue to execute the tasks backward;

[0079] Step 3.11: Level2 starts to execute Function A module:

[0080] Step 3.11.1: After the program execution of Function A module ends, core1 reads the intermediate result of Function A module executed by Level1 in the shared storage area and compares the data of the same function processed by Level2;

[0081] Step 3.11.2: If the difference between the two is large, indicating a problem, core1 will send an interrupt request to the relevant interrupt handling module;

[0082] Step 3.11.3: The system responds to the interrupt and uses the system log to roll back core0 and core1 to the previous loop state;

[0083] Step 3.11.4: Then, enter the fault handling mechanism, perform gradient limitation according to the size of the difference. When the difference is small but exceeds the normal fluctuation range, the system takes restrictive responses, such as restricting the upper limit of torque output to a certain threshold; when the difference is large, at this time, in addition to restrictive responses (i.e., restricting power output), the system may further reduce the vehicle speed; when the difference exceeds the maximum tolerance threshold, the system will enforce an emergency stop and cut off the connection with the power system;

[0084] Step 3.11.5: If the data comparison in Step 3.12 is normal, the system log will be updated, and Level2 will continue to execute the task process backward;

[0085] Step 3.12: The same as the execution steps of Function A module, execute Function B, C, and D modules in sequence. When each function module execution ends, it will obtain the intermediate result of the corresponding function module from the shared storage area and compare it with it. According to the data difference, determine whether to continue executing the task and update the system log or the system enters the safe state;

[0086] Step 3.13: After the execution of this task ends, core1 will continue to execute the next task.

[0087] By functionally partitioning a complete task, the present invention runs Level 1 and Level 2 in different cores, enabling the programs with the same functions to be executed in different cores and at different time periods for the Level 1 layer and the Level 2 layer, thus solving the problem of common cause failure.

[0088] The present invention does not consider data security issues for the Level 1 layer and uses plaintext plus MAC as the input for the Level 2 layer. Therefore, there is a message authentication delay in the Level 2 layer, which also creates conditions for the asynchrony of the execution of the Level 1 and Level 2 programs.

[0089] When performing message authentication in the Level 2 layer, the present invention will set a timer to prevent the increase in the delay of the Level 2 layer caused by the stagnation of the HSM module.

[0090] It should be noted that in this article, the term "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or device including a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or device. Without further limitation, an element defined by the statement "including a..." does not exclude the existence of additional identical elements in the process, method, article, or device including that element.

[0091] The above are only the preferred embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made by using the specification and drawings of the present invention, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of the present invention.

Claims

1. A controller Level 2 functional safety monitoring method integrating information security, characterized in that: By dividing a complete task into multiple functional modules, and making Level1 and Level2 run in different cores; the Level1 layer directly uses plain text data as input, and the Level2 layer uses plain text plus MAC as input. Due to the delay caused by the Level2 layer message authentication, there is asynchrony between Level1 and Level2 when executing the same functional program; in addition, a shared storage area is established to store the intermediate results of the execution of the Level1 layer functional module, reducing the communication delay between core0 and core1; By recording system logs to restore the system to a safe state in case of failure; The core1 execution process includes: Step 3.1: core1 is used for Level2 layer. First, it receives data in the form of plain text plus MAC as input of Level2 layer; Step 3.2: Then, the Level2 layer authenticates the input data with the help of the HSM module, and core1 sends a message authentication request to the HSM core through an interrupt; Step 3.3: At the same time, core1 starts the timer; Step 3.4: The HSM core responds to the interrupt according to its own status. If the HSM core has no task to process at this time, it will provide feedback to core1 through the interrupt response; Step 3.5: After core1 receives the interrupt response, it sends the data to be processed to the HSM core; Step 3.6: The HSM core performs integrity check on the received data. The encryption engine inside the HSM core uses the key pre-stored in its secure storage area to calculate the plaintext data according to the CMAC / HMAC algorithm to obtain a new MAC value. Step 3.7: Verify the calculated MAC value with the received MAC value. During this process, core1 continues to detect the timer time; Step 3.8: If the timer does not exceed the threshold and the verification fails: Step 3.8.1: The HSM core sends a failure command to core1 via an interrupt; Step 3.8.2: core1 sends a serious error warning signal to the driver through a communication interface connected to the driver display device; Step 3.8.3: The system enters a safe state, and core1 guides the system into the rollback process through an interrupt; Step 3.8.4: Read the system log and roll back core0 and core1 to the previous cycle state, that is, the state after executing a complete round of functional modules; Step 3.8.5: Then, enter the fault handling mechanism and adopt the same handling method as when the difference is abnormally large during the function execution stage, limit the power output of the motor and reduce the vehicle speed; Step 3.9: If the timer exceeds the threshold, the Level 2 layer will directly skip the message authentication and the system will send a warning signal to the driver; Step 3.10: If step 3.8 is verified successfully or step 3.9 is executed, the system log is updated and the Level 2 layer continues to execute the task backward; Step 3.11: Level 2 starts executing function A module: Step 3.11.1: After the program execution of function A module is completed, core1 reads the intermediate result of Level1 executing function A module in the shared storage area and compares it with the data of the same function processed by Level2; Step 3.11.2: If the difference between the two is large, it means there is a problem, and core1 will send an interrupt request to the relevant interrupt processing module; Step 3.11.3: The system responds to the interruption and uses the system log to roll back core0 and core1 to the previous cycle state; Step 3.11.4: Then, the fault handling mechanism is entered, and gradient limitation is performed according to the size of the difference. When the difference is small but exceeds the normal fluctuation range, the system takes a limiting response; when the difference is large, in addition to the limiting response, the system will further reduce the vehicle speed; when the difference exceeds the maximum tolerance threshold, the system will force an emergency shutdown and cut off the connection with the power system; Step 3.11.5: If the data comparison in step 3.12 is normal, the system log is updated and the Level 2 layer will continue to execute the task flow backwards; Step 3.12: The same as the execution steps of function A module, execute function B, C and D modules in sequence. When each function module is executed, the intermediate result of the corresponding function module will be obtained from the shared storage area and compared with it. According to the data difference, it is determined whether to continue to execute the task and update the system log or the system enters a safe state; Step 3.13: The task is completed and core1 will continue to execute the next task.

2. According to the method for monitoring the Level 2 functional safety of a controller integrating information security in claim 1, it is characterized in that: The initialization of the system includes the following steps: Step 1.1: When the system is initialized, the task is divided into four functional modules, including function A, B, C and D modules; Step 1.2: Create a shared memory area and initialize blocks for each functional module for use by core0 and core1; Step 1.3: The system initializes and starts the logging mechanism at the same time. The system log records contain the status, intermediate results and key information of core0 and core1 during the execution of each functional module, providing support for status rollback.

3. According to the method for monitoring the Level 2 functional safety of a controller integrating information security in claim 2, it is characterized in that: The core0 execution process includes: Step 2.1: Transmit the communication data from other controllers to core0 in plain text as the input signal of Level 1 layer; Step 2.2: Level 1 starts to execute the function A module in the task; Step 2.2.1: After the program execution of function A module is completed, core0 stores the intermediate results of function A module into the corresponding block of the shared memory area; Step 2.2.2: Update the system log to record the status at this moment; Step 2.3: The same as the execution steps of function A module, execute function B, C and D modules in sequence, store the intermediate results in the shared storage area after each function module is completed, and update the system log; Step 2.4: The task is completed and core0 will continue to execute the next task.

Images