Function security cloud system based on endogenous security design and implementation method thereof

Abstract

The invention discloses a functional security cloud system based on endogenous security design and an implementation method thereof, the system is deployed on a cloud platform, and the system comprises a functional security core management layer for defining and managing security requirements and states of workloads on the cloud; the endogenous security execution environment module is used for acquiring heterogeneous resources according to security requirements, creating and managing a dynamic redundancy unit for a working load, and outputting a consistent result through a mimicry scheduling and multi-mode decision mechanism; the security situation awareness and collaborative response module is used for monitoring the operation situation of the system and analyzing abnormal events; the module reports an abnormal event to a functional security core management layer; and the functional security core management layer drives the workload to perform security state transition and issues a corresponding control instruction to the execution environment. Compared with the prior art, deep fusion and integrated guarantee of function security and network security on a cloud platform are realized through a closed-loop mechanism of security event-driven service state transition and state decision feedback control security execution.

Description

Technical Field

[0001] This invention relates to the fields of cloud computing and network security technology, and in particular to a functional safety cloud system based on intrinsic safety design and its implementation method. Background Technology

[0002] With the development of Industry 4.0, the Internet of Things, and edge computing, an increasing number of critical systems in the rail transit field are adopting cloud-native architectures to gain advantages such as elastic scaling, efficient operation and maintenance, and global deployment. However, traditional cloud platforms face significant challenges in addressing functional safety requirements: 1. Separation of network security and functional safety: A typical solution is to overlay external security protection measures, such as firewalls and intrusion detection systems, on top of the cloud platform. This kind of external security is lagging behind and is difficult to deal with unknown attacks from within. Once it is bypassed, the functional safety of the entire system will collapse instantly. 2. Uncertainty: The multi-tenancy and dynamic resource scheduling characteristics of cloud platforms introduce unpredictability in performance and failure, which contradicts the determinism and predictability required by functional safety standards. 3. Difficulty in distinguishing between faults and attacks: Traditional functional safety mainly deals with random hardware failures and systemic software failures, while cybersecurity threats are intelligent and malicious. In a cloud environment, a malicious attack may manifest as a series of seemingly unrelated random failures, making it impossible for the system to properly trace the source and respond. 4. Certification difficulties: Existing functional safety certifications are designed for relatively static embedded systems. For continuously evolving and dynamically changing cloud services, traditional functional safety certification processes are difficult to apply.

[0003] A search revealed Chinese Patent Publication No. CN116471116A, which discloses an intrinsically secure cloud platform and its construction method. This solution constructs a heterogeneous execution entity resource pool and utilizes user-side and business-side proxy adjudication units to perform mimicry adjudication on the outputs of multiple execution entities. Then, a feedback control unit cleans or replaces abnormal execution entities, thereby improving the cloud platform's control service's resistance to attacks and reliability. However, this solution primarily focuses on the intrinsic security protection of the cloud platform's control plane, lacking a functional safety core management layer and a security posture coordination and response mechanism. It cannot define and manage functional safety integrity levels for cloud-based business workloads, nor can it achieve closed-loop coordination between intrinsic security recovery based on security events and functional safety state migration. Therefore, it struggles to meet the integrated protection needs of critical business scenarios with stringent functional safety requirements.

[0004] Therefore, how to achieve deep integration and collaborative protection of the functional security requirements of business and the inherent security requirements of the system on the cloud platform is a technical problem that needs to be solved. Summary of the Invention

[0005] The purpose of this invention is to overcome the defects of the prior art by providing a functional safety cloud system based on intrinsic safety design and its implementation method.

[0006] The objective of this invention can be achieved through the following technical solutions: According to a first aspect of the present invention, a functional safety cloud system based on intrinsic safety design is provided, the system being deployed on a cloud platform, comprising: The functional safety core management layer defines and manages the functional safety requirements and safety status of workloads running on the cloud platform. The intrinsically safe execution environment module is connected to the functional safety core management layer. In response to the functional safety requirements, it obtains computing resources that meet the heterogeneity constraints. Based on the computing resources, it creates and manages dynamic heterogeneous redundant units consisting of multiple functionally equivalent but heterogeneous execution entities for the workload, and outputs consistent results through mimicry scheduling and multi-mode adjudication mechanisms. The security situation awareness and collaborative response module is connected to the functional safety core management layer and the intrinsic security execution environment module, and is used to monitor the system operation status and analyze abnormal events. The security situation awareness and collaborative response module reports the abnormal event to the functional safety core management layer; the functional safety core management layer responds to the abnormal event, drives the security state migration of the workload, and issues control instructions corresponding to the migrated security state to the intrinsically secure execution environment module.

[0007] As a preferred technical solution, the functional safety core management layer includes: A safety status controller is used to define and manage system-level safety statuses, including normal operation status, degraded operation status, and safe shutdown status. The security requirement injection interface receives the functional security requirement level and security policy defined by the user for the workload. The Safety Lifecycle Manager is used to manage the verification, updating, and decommissioning of functional safety configurations.

[0008] As a preferred technical solution, the intrinsically secure execution environment module includes: The dynamic heterogeneous redundancy unit schedules and manages multiple execution entities for the workload, and the heterogeneity between the execution entities includes hardware platform heterogeneity, software stack heterogeneity, or algorithm implementation heterogeneity. The mimicry scheduler and adjudicator is connected to the dynamic heterogeneous redundancy unit. It distributes the input data of the workload to each executor using a non-fixed scheduling strategy, and performs real-time multi-mode adjudication based on the output results of each executor to identify abnormal executors.

[0009] As a preferred technical solution, the mimicry scheduler and arbitrator is further used for: After identifying the abnormal executor, the isolation, cleaning, or reset operation of the abnormal executor is triggered, and a new heterogeneous executor is rescheduled and started on a resource node that meets the heterogeneity constraint to restore the redundancy of the dynamic heterogeneous redundancy unit.

[0010] As a preferred technical solution, the intrinsically secure execution environment module further includes: The Trusted Computing Base, built upon a hardware root of trust, is used to establish and verify a chain of trust from hardware boot, the system kernel, to the intrinsically secure execution environment module.

[0011] As a preferred technical solution, the security situation awareness and collaborative response module includes: A unified monitoring probe is used to collect runtime data from the system kernel layer, container layer, virtual machine layer, network layer, and each execution entity in the intrinsically secure execution environment module. The AI ​​analysis engine is used to perform correlation analysis on the collected data to distinguish between random failures and coordinated attacks. The collaborative response engine is used to report the event to the functional safety core management layer and trigger a preset system-level security state transition when the AI ​​analysis engine detects an attack or fault.

[0012] As a preferred technical solution, the system further includes: The security resource scheduler is connected to the functional safety core management layer and the intrinsically secure execution environment module. In response to control commands or initial scheduling requests from the functional safety core management layer, it schedules and allocates computing resources that meet preset heterogeneity constraints and geographical isolation requirements for the dynamic heterogeneous redundant unit.

[0013] As a preferred technical solution, the control instructions issued by the functional safety core management layer to the security resource scheduler include: increasing the number of redundant copies of the dynamic heterogeneous redundancy unit for a specified workload, adjusting the heterogeneity strategy between executors, or migrating the executor to a different physical fault domain.

[0014] According to a second aspect of the present invention, a method for implementing the system is provided, the method comprising: The functional safety core management layer receives and manages functional safety requirements and security status for workloads. Based on the aforementioned functional safety requirements, computing resources that satisfy heterogeneity constraints are obtained; Through the intrinsically secure execution environment module, a dynamic heterogeneous redundant unit is built and run for the workload based on the computing resources, and business requests are processed using a mimicry scheduling and multi-mode adjudication mechanism. The security situation awareness and collaborative response module monitors system operation and analyzes and generates abnormal events. The abnormal event shall be reported to the functional safety core management layer. In response to the abnormal event, the functional safety core management layer drives the security state migration of the workload and issues control commands to the intrinsically secure execution environment module based on the migrated security state.

[0015] As a preferred technical solution, the step of constructing and running a dynamic heterogeneous redundancy unit for the workload includes: Based on the functional safety requirements, multiple functionally equivalent but heterogeneous executors are scheduled, and the heterogeneity is implemented based on hardware architecture, software stack or algorithm. Input is distributed to each executor in a non-fixed manner through a mimicry scheduler; The arbitrator performs multi-mode adjudication on the output of each executor, outputs consistent results, and identifies abnormal executors.

[0016] As a preferred technical solution, the method further includes: When an abnormal executor is identified, a recovery process is automatically triggered, including isolating the abnormal executor and starting a new executor on a resource node that meets the heterogeneous constraints, in order to restore dynamic heterogeneous redundancy.

[0017] As a preferred technical solution, the safe state transition of the workload includes: The functional safety core management layer assesses the level and impact of the abnormal event based on a predefined state transition strategy. Based on the assessment results, the security status of the workload is switched from the current state to the target state, which includes degraded operation or safe shutdown.

[0018] As a preferred technical solution, control commands are issued to the intrinsically secure execution environment module based on the migrated security state, including: If the security status after migration is degraded operation, the control instructions include reducing the service performance level but maintaining core security functions; If the safety status after migration is safe shutdown, then the control instructions include safely terminating all executors and saving critical states.

[0019] Compared with the prior art, the present invention has the following advantages: 1. This invention integrates the functional safety core management layer, the intrinsic safety execution environment module, and the security situation awareness and collaborative response module into a single design. It deeply couples functional safety state management, demand-driven operations, and intrinsic safety dynamic heterogeneous redundancy and proactive adjudication mechanisms. Furthermore, it enables cross-layer event reporting and instruction issuance through the collaborative response module. This achieves deep integration and collaborative protection of functional safety requirements and intrinsic safety requirements at the system architecture and operational logic levels.

[0020] 2. This invention constructs an inherent proactive defense capability by creating dynamic heterogeneous redundant units for the workload and adopting a mimicry scheduling and multi-mode adjudication mechanism. This design enables the system to tolerate random failures and effectively resist unknown attacks that exploit specific vulnerabilities. Even if some execution units are compromised, the system can still output correct results, thereby improving the availability and security of the system.

[0021] 3. Based on the security state migration and automatic recovery mechanism of abnormal events, this invention enables the system to have adaptive elasticity. When an attack or fault is detected, it can not only automatically isolate the abnormal execution body and rebuild redundancy, but also drive the intelligent switching of the security state at the global or load level of the system. This realizes the linkage from local anomaly handling to overall security policy adjustment, and enhances the survivability and service availability of the system in a continuous threat environment. Attached Figure Description

[0022] Figure 1 This is a system architecture diagram of the present invention; Figure 2 This is a schematic diagram illustrating the working principle of the dynamic heterogeneous redundancy unit of the present invention; Figure 3 This is a flowchart illustrating the collaborative response of the system of the present invention when subjected to a network security attack. Figure 4 This is a flowchart of the method of the present invention; Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0024] Example 1: like Figure 1 As shown, this invention provides a functional safety cloud system based on intrinsic safety design. This system deeply integrates functional safety management and intrinsic safety execution, providing highly reliable and highly available safety assurance for critical cloud-based services such as rail transit control and autonomous driving simulation. Specifically, it includes: Functional safety core management layer: Responsible for integrating functional safety concepts into cloud management, including: Security State Controller: Based on a predefined finite state machine model, it manages the security state of the system and each workload. Typical states include: Normal operation, with all security mechanisms in place and full performance enabled; Degraded operation, where some security mechanisms are active or performance is limited, but core security functions are maintained; and Safe shutdown, where services are stopped in an orderly manner, critical states are preserved, and dangers are prevented. State transitions are event-driven.

[0025] Security Requirements Injection Interface: Provides an entry point for users or upper-layer applications to define security objectives. For example, when deploying an autonomous driving simulation task, users can use this interface to specify their required security integrity level, such as SIL-3, and define specific security policies, such as maximum response latency, minimum number of available replicas, and allowed fault recovery time target (RTO).

[0026] Security Lifecycle Manager: Manages the entire lifecycle of functional safety-related configurations, software versions, policies, and rules. Any changes, such as system upgrades or policy updates, must undergo an impact assessment to ensure that no uncontrollable security risks or violations of established security requirements are introduced.

[0027] Endogenous Secure Execution Environment Module: Based on the concept of mimicry defense, a deterministic and reliable output is generated in an uncertain threat environment through dynamic heterogeneous redundancy and proactive adjudication mechanism.

[0028] Dynamic Heterogeneous Redundancy Unit Construction Unit: When the functional safety core management layer determines that a certain workload requires high-level protection, the system will create a dynamic heterogeneous redundancy unit for it. This unit consists of multiple (N≥2) functionally equivalent but heterogeneously implemented execution entities. The heterogeneity is reflected in: (1) hardware heterogeneity: such as some execution entities running on x86 servers and some running on Arm servers; (2) software stack heterogeneity: such as using different versions of operating systems, middleware or runtime libraries; (3) algorithm heterogeneity: using algorithms with different implementation principles for critical calculations. This design aims to eliminate common-mode failures and attack points.

[0029] Mimicry scheduling and adjudicators: such as Figure 2As shown, this is the core engine of intrinsic security. The mimicry scheduler receives business input requests and distributes them to various heterogeneous executors within the redundant unit using non-fixed and unpredictable scheduling strategies (such as dynamic algorithms combining random, round-robin, and load-weighted scheduling). The arbitrator synchronously collects the outputs of all executors and adopts a multi-mode arbitration mechanism. That is, when the outputs of a majority (such as 2 / 3) of the executors are consistent, the consistent result is accepted as the final output. If the output of an executor consistently deviates from the majority, it is judged as an abnormal executor. This mechanism can effectively shield errors caused by single-point hardware or software failures or the exploitation of unknown vulnerabilities.

[0030] Trusted Computing Base: Based on the hardware root of trust within the server, such as TPM / TPCM chips or Intel SGXenclave, a trust chain is built during the system startup phase, from the hardware firmware, bootloader, operating system kernel to cloud platform security components, to ensure that the code and configuration loaded by the intrinsically secure execution environment module itself are trustworthy and have not been tampered with.

[0031] Security Situation Awareness and Collaborative Response Module: like Figure 3 As shown, this module is responsible for panoramic monitoring, intelligent analysis, and driving cross-layer responses to achieve cross-layer secure collaboration. Unified monitoring probes: Lightweight probes are deployed at various levels of the system: the host kernel, container runtime, virtual machine monitor, network devices, and inside each heterogeneous execution entity. They collect performance metrics (CPU / memory usage), system logs, network traffic, and security events in real time, such as abnormal system calls and file access violations.

[0032] AI analysis engine: performs real-time correlation and fusion analysis on massive monitoring data, and uses machine learning models such as anomaly detection models trained on historical data to distinguish between random hardware failures (usually isolated and short-lived) and coordinated network attacks (which may exhibit spatiotemporal correlation and slow characteristics).

[0033] Collaborative Response Engine: When the AI ​​analysis engine confirms a security incident or the arbitrator outputs an abnormal judgment, the collaborative response engine is activated. Issue disposal instructions to the intrinsically secure execution environment module: for example, instruct the container orchestration system (such as Kubernetes) to immediately isolate the marked abnormal execution and quickly launch a new replica on another node that meets the heterogeneity requirements (such as different CPU architectures) to restore the integrity and protection capabilities of the redundant unit; Reporting incidents to the core functional safety management layer and driving state transitions: Information such as the severity and scope of the attack is reported. Based on preset policies, the safety state controller may decide to migrate the entire system or the affected workload from the normal operating state to a degraded operating state, such as restricting non-critical functions, ensuring the security of the core control loop, and issuing warnings to upstream business systems.

[0034] Security Resource Scheduler: It maintains a resource profile containing tags such as node hardware architecture, operating system version, geographical location, and fault domain. When a request is received to construct resources for a dynamic heterogeneous redundant unit, its scheduling algorithm prioritizes safety constraints: first, it filters out a list of nodes that meet geographical isolation requirements (such as belonging to different availability zones); then, it selects the combination of nodes with the greatest differences in hardware or software stacks from different fault domains; and finally, it considers the remaining amount of CPU and memory. This ensures that the execution entities of the redundant unit have the greatest degree of diversity, fundamentally avoiding common-mode failures.

[0035] The system of this invention achieves local self-healing at the intrinsic layer when an attack or fault is detected through deep collaboration among its various modules. It can also report security events to the management layer and drive the business load to perform system-level security state migration, thereby realizing a closed-loop intelligent response from network attack protection to business function assurance.

[0036] Example 2: like Figure 4 As shown, the present invention provides a method for implementing the above system. Taking an autonomous driving simulation scenario deployed on a functional safety cloud based on intrinsic safety design as an example, the method mainly includes the following steps: Step S1: Define clear functional safety objectives for cloud workloads through the security requirements interface, such as specifying the required Security Integrity Level (SIL), performance metrics, and security policies; Step S2: Based on the security requirements defined in S1, automatically schedule computing resources that meet the constraints of hardware heterogeneity (such as x86 and Arm) and geographical isolation, and build a dynamic redundant unit for the workload consisting of multiple functionally equivalent but heterogeneously implemented execution entities; Step S3: The business input is distributed to all heterogeneous executors in a non-fixed manner through the mimicry scheduler; each executor processes and outputs results independently, and the arbitrator performs real-time multi-mode adjudication, outputs consistent results, and identifies abnormal executors; Step S4: Collect real-time operational data of the system kernel, containers, network, and heterogeneous execution entities through probes deployed at each layer; use an AI engine to perform correlation analysis to distinguish between random failures and coordinated network attacks, and generate accurate security events. Step S5: Based on the perception results of step S4, trigger a two-way collaborative response: 1) Intrinsic security layer: isolate / reset the abnormal execution body, and rebuild the copy on the new node that meets the heterogeneous constraints to restore redundancy; 2) Functional security layer: drive the security state of the workload, such as migrating from normal operation to degraded operation, and issue corresponding control commands to achieve self-healing and continuous protection under attack and failure.

[0037] The following example, using an autonomous driving simulation scenario deployed on a functional safety cloud based on intrinsic safety design, illustrates the method of this invention: Step S101: The user submits an autonomous driving perception algorithm simulation task through the security requirement injection interface and specifies its functional safety requirements: the safety integrity level is SIL-3, the task availability is required to be no less than 99.999%, the maximum end-to-end latency is 100 milliseconds, and the computing resources are required to have hardware heterogeneity (such as x86 and Arm coexistence) to achieve intrinsic safety; Step S102: Upon receiving the request, the security resource scheduler, or the scheduler modified by the cloud platform according to the policy, executes a security scheduling decision: Select resources from the resource pool that meet the constraints of hardware heterogeneity and geographical isolation: for example, select a server with an Intel CPU in Availability Zone A and a server with an AWS Graviton (Arm) processor in Availability Zone B. On two servers, an executor is scheduled and launched respectively. These two executors run the same simulation algorithm, but are based on different base images (such as one using Ubuntu Linux and the other using Alpine Linux) and different versions of mathematical libraries to increase the heterogeneity of the software stack. The system logically binds these two heterogeneous executors to form a dynamic heterogeneous redundant unit that serves the simulation task. Step S103: Simulation task begins running: After receiving each frame of simulated sensor data, the mimic scheduler simultaneously distributes it to two heterogeneous actuators within the redundant unit in a dynamically changing order. The two actuators perform perception calculations independently, such as target recognition and distance estimation; The arbiter collects the outputs of both and compares them: Case A (Normal): The calculation results of both are consistent within the allowable fault tolerance range, the arbiter outputs the consistent result, and the simulation task continues; Case B (Abnormal): The calculation result of the Arm executor deviates slightly due to an undisclosed runtime library vulnerability. The arbiter finds the inconsistency through comparison. According to the multi-mode arbitration principle, the majority result is the result of the x86 executor. The result of the x86 executor is adopted as the final output. At the same time, the Arm executor is marked as abnormal. Step S104: The security situation awareness module continues to operate: The unified monitoring probe collected a large number of abnormal memory access pattern logs within the Arm execution container; The AI ​​analysis engine correlated these logs with minute abnormal data packets that the network layer failed to identify, determining that this was not a random memory error, but rather a suspected data poisoning or algorithm perturbation attack targeting a specific algorithm or library. Step S105: The collaborative response engine is triggered, and the linked response is executed: Intrinsic security layer recovery: The engine immediately notifies the Kubernetes control plane to isolate the Arm executable container marked as abnormal, and based on the security resource scheduler's policy, quickly rebuilds and starts a new executable on another node that meets heterogeneous constraints with the existing x86 executable (such as a different type of Arm server or a different software stack). The protection capability of the dynamic heterogeneous redundancy unit automatically recovers in a short time; Functional safety layer state transition: The engine reports the severity of this attack (determined to be a coordinated attack, not a random failure) to the functional safety core management layer. After evaluating the situation according to the preset strategy, the safety state controller considers the current threat level to be high and decides to switch the security state of the simulation task and its related system components from normal operation to degraded operation. In this state, the system may automatically shut down some non-critical simulation visualization rendering functions to save computing power, while ensuring that the core control algorithm simulation loop continues to run with the highest priority and redundancy protection, and sending an alarm to the simulation platform administrator.

[0038] The method of this invention realizes a complete closed loop from security requirement definition, security resource preparation, runtime proactive defense, to threat response and system self-healing. When a network attack occurs, it can ensure the correctness of the output results through the intrinsic security mechanism, and can also intelligently assess the impact of the attack, dynamically adjust the system operating status, and automatically repair damaged components, realizing the deep integration and collaborative protection of functional safety and intrinsic security in the cloud environment.

[0039] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A functional safety cloud system based on intrinsic safety design, characterized in that, The system is deployed on a cloud platform and includes: The functional safety core management layer defines and manages the functional safety requirements and safety status of workloads running on the cloud platform. The intrinsically safe execution environment module is connected to the functional safety core management layer. In response to the functional safety requirements, it obtains computing resources that meet the heterogeneity constraints. Based on the computing resources, it creates and manages dynamic heterogeneous redundant units consisting of multiple functionally equivalent but heterogeneous execution entities for the workload, and outputs consistent results through mimicry scheduling and multi-mode adjudication mechanisms. The security situation awareness and collaborative response module is connected to the functional safety core management layer and the intrinsic security execution environment module, and is used to monitor the system operation status and analyze abnormal events. The security situation awareness and collaborative response module reports the abnormal event to the functional safety core management layer; the functional safety core management layer responds to the abnormal event, drives the security state migration of the workload, and issues control instructions corresponding to the migrated security state to the intrinsically secure execution environment module.

2. A functional safety cloud system based on intrinsic safety design according to claim 1, characterized in that, The functional safety core management layer includes: A safety status controller is used to define and manage system-level safety statuses, including normal operation status, degraded operation status, and safe shutdown status. The security requirement injection interface receives the functional security requirement level and security policy defined by the user for the workload. The Safety Lifecycle Manager is used to manage the verification, updating, and decommissioning of functional safety configurations.

3. A functional safety cloud system based on intrinsic safety design according to claim 1, characterized in that, The intrinsically secure execution environment module includes: The dynamic heterogeneous redundancy unit schedules and manages multiple execution entities for the workload, and the heterogeneity between the execution entities includes hardware platform heterogeneity, software stack heterogeneity, or algorithm implementation heterogeneity. The mimicry scheduler and adjudicator is connected to the dynamic heterogeneous redundancy unit. It distributes the input data of the workload to each executor using a non-fixed scheduling strategy, and performs real-time multi-mode adjudication based on the output results of each executor to identify abnormal executors.

4. A functional safety cloud system based on intrinsic safety design according to claim 3, characterized in that, The mimicry scheduler and adjudicator is also used for: After identifying the abnormal executor, the isolation, cleaning, or reset operation of the abnormal executor is triggered, and a new heterogeneous executor is rescheduled and started on a resource node that meets the heterogeneity constraint to restore the redundancy of the dynamic heterogeneous redundancy unit.

5. A functional safety cloud system based on intrinsic safety design according to claim 3, characterized in that, The intrinsically secure execution environment module also includes: The Trusted Computing Base, built upon a hardware root of trust, is used to establish and verify a chain of trust from hardware boot, the system kernel, to the intrinsically secure execution environment module.

6. A functional safety cloud system based on intrinsic safety design according to claim 1, characterized in that, The security situation awareness and collaborative response module includes: A unified monitoring probe is used to collect runtime data from the system kernel layer, container layer, virtual machine layer, network layer, and each execution entity in the intrinsically secure execution environment module. The AI ​​analysis engine is used to perform correlation analysis on the collected data to distinguish between random failures and coordinated attacks. The collaborative response engine is used to report the event to the functional safety core management layer and trigger a preset system-level security state transition when the AI ​​analysis engine detects an attack or fault.

7. A functional safety cloud system based on intrinsic safety design according to claim 1, characterized in that, The system also includes: The security resource scheduler is connected to the functional safety core management layer and the intrinsically secure execution environment module. In response to control commands or initial scheduling requests from the functional safety core management layer, it schedules and allocates computing resources that meet preset heterogeneity constraints and geographical isolation requirements for the dynamic heterogeneous redundant unit.

8. A functional safety cloud system based on intrinsic safety design according to claim 7, characterized in that, The control instructions issued by the functional safety core management layer to the safety resource scheduler include: increasing the number of redundant copies of the dynamic heterogeneous redundancy unit for a specified workload, adjusting the heterogeneity strategy between executors, or migrating executors to different physical fault domains.

9. A method for implementing the system according to any one of claims 1-8, characterized in that, include: The functional safety core management layer receives and manages functional safety requirements and security status for workloads. Based on the aforementioned functional safety requirements, computing resources that satisfy heterogeneity constraints are obtained; Through the intrinsically secure execution environment module, a dynamic heterogeneous redundant unit is built and run for the workload based on the computing resources, and business requests are processed using a mimicry scheduling and multi-mode adjudication mechanism. The security situation awareness and collaborative response module monitors system operation and analyzes and generates abnormal events. The abnormal event shall be reported to the functional safety core management layer. In response to the abnormal event, the functional safety core management layer drives the security state migration of the workload and issues control commands to the intrinsically secure execution environment module based on the migrated security state.

10. The method according to claim 9, characterized in that, The construction and operation of dynamic heterogeneous redundancy units for the workload includes: Based on the functional safety requirements, multiple functionally equivalent but heterogeneous executors are scheduled, and the heterogeneity is implemented based on hardware architecture, software stack or algorithm. Input is distributed to each executor in a non-fixed manner through a mimicry scheduler; The arbitrator performs multi-mode adjudication on the output of each executor, outputs consistent results, and identifies abnormal executors.

11. The method according to claim 10, characterized in that, The method further includes: When an abnormal executor is identified, a recovery process is automatically triggered, including isolating the abnormal executor and starting a new executor on a resource node that meets the heterogeneous constraints, in order to restore dynamic heterogeneous redundancy.

12. The method according to claim 9, characterized in that, The safe state transition that drives the workload includes: The functional safety core management layer assesses the level and impact of the abnormal event based on a predefined state transition strategy. Based on the assessment results, the security status of the workload is switched from the current state to the target state, which includes degraded operation or safe shutdown.

13. The method according to claim 9, characterized in that, Based on the migrated security state, control commands are issued to the intrinsically secure execution environment module, including: If the security status after migration is degraded operation, the control instructions include reducing the service performance level but maintaining core security functions; If the safety status after migration is safe shutdown, then the control instructions include safely terminating all executors and saving critical states.

Images