Dynamic Defense Mechanism for Programmable Logic Controllers: A Heterogeneous Multi-Core Architecture with Rapid Nanosecond-Scale Threat Perception

Abstract

Existing PLC security solutions face a fundamental conflict between stringent real-time requirements and robust protection: traditional IT security mechanisms (e.g., encryption, authentication) introduce unacceptable latency, while software-based redundancy schemes operate at millisecond scale and remain vulnerable to common-cause failures. To bridge this gap, this study proposes MimicPLC v1.0, a dynamic defense mechanism based on a heterogeneous multi-core architecture that integrates threat perception, dynamic fault tolerance, and rapid recovery within a single chip, thereby reconciling real-time determinism with proactive security in industrial control systems. The architecture integrates three distinct CPU cores (MIPS, ARM, and RISC-V) within a single system-on-chip (ESC0830), coordinated by a dedicated hardware-based mimic scheduling subsystem. This subsystem performs real-time, loosely coupled, transaction-level consistency checks on the AHB-Lite bus operations of the heterogeneous processors, achieving nanosecond-scale arbitration latency for threat detection. We evaluate the proposed design using an industrial-strength testbed, incorporating a custom development board and the Synopsys Verdi simulation environment, under critical attack scenarios including Denial-of-Service (DoS), replay, code injection, and parameter overwrite attacks. The system maintains continuous operation through adaptive redundancy, demonstrating attack perception within 73 clock cycles and leveraging instruction-set asymmetry for effective threat containment. Rigorous validation, including 100 consecutive parameter override attacks, confirms a 100% interception rate within our tested attack scenarios, with zero false positives observed. The design complies with the IEC 61131-3 real-time standard, exhibiting a worst-case recovery duration of 9.3 ms and a 95% confidence interval for recovery latency of [4.0354, 4.0363] ms. This work pioneers a paradigm of rapid-detection endogenous security with nanosecond-scale arbitration for next-generation industrial control systems.

1. Introduction

The accelerating digital transformation of Industrial Control Systems (ICS) has positioned Programmable Logic Controllers (PLCs) as both critical operational hubs and prime attack surfaces in modern industrial infrastructure. As evidenced by escalating Advanced Persistent Threat (APT) incidents—from Stuxnet’s covert centrifugal sabotage in 2010 [1], to the TRITON attack targeting safety instrumented systems in 2017 [2], and the more recent Industroyer malware designed to disrupt power grid substations [3]—contemporary attackers systematically exploit firmware vulnerabilities, protocol weaknesses, and architectural flaws in PLCs to bridge cyber-physical attack vectors. These incidents reveal a common pattern: once attackers penetrate the perimeter defenses, the homogeneous architecture of conventional PLCs offers little resistance to lateral movement and payload execution. This security crisis has galvanized cross-disciplinary efforts to develop multi-layered defense paradigms spanning perimeter hardening, system resilience, and intrinsic security mechanisms. This study systematically examines four principal technological trajectories in secure PLC evolution: conventional IT security adaptations, system-level fortification, built-in security architectures, and redundancy-based fault tolerance, while critically analyzing their implementation challenges and industrial applicability.

1.1. Conventional IT Security Adaptations

Traditional cybersecurity frameworks leveraging cryptographic algorithms, authentication protocols [4], and access control mechanisms demonstrate proven efficacy in general computing environments. However, their direct transplantation to industrial control domains reveals fundamental challenges in meeting PLCs’ real-time operational constraints and protocol-specific requirements. We acknowledge that this challenge has been recognized and addressed by several prior studies [5,6]; however, these approaches predominantly rely on software-based monitoring agents or external security gateways deployed between the PLC and the field network. While effective at a coarse granularity, such methods inherently introduce additional processing latency due to software execution overhead and inter-chip communication delays. In contrast, our proposed approach embeds the security arbitration logic directly within the PLC’s processing chip as dedicated hardware, achieving detection latencies that are orders of magnitude lower than software-based alternatives. Empirical studies indicate that TLS handshake-induced millisecond latency [7] can destabilize high-speed motion control loops, while forced integration of security layers with legacy industrial protocols like Modbus frequently triggers parsing anomalies [8], inadvertently creating new attack surfaces. These incompatibility issues underscore the imperative for domain-specific security solutions tailored to industrial operational technology (OT) ecosystems.

1.2. System-Level Fortification Strategies

The system-level hardening approach focuses on securing control systems that closely interact with PLCs, typically involving two critical dimensions: interactions with lower-layer field devices (e.g., sensors and actuators) [9], and communications with upper-layer supervisory systems (including SCADA, DCS, HMI, Manufacturing Execution Systems (MES), and Enterprise Resource Planning (ERP) platforms). Typical implementations include establishing an industrial demilitarized zone (DMZ) to isolate PLCs from IT networks [10], thereby effectively reducing the risks of penetration from external attacks. Another strategy involves collecting PLC operational data to construct behavioral baselines using machine learning algorithms or rule-based engines, enabling real-time anomaly detection [11,12]. While this hierarchical defense methodology enhances overall security through layered protection and continuous monitoring, its application in PLC protection faces constraints owing to inherent limitations such as centralized architectural dependencies and elevated false positive rates.

1.3. Built-In Security Architectures

The built-in security framework integrates security capabilities directly into the underlying architecture of PLCs, addressing vulnerabilities at the program, firmware, and memory levels [13,14]. To illustrate this paradigm, consider firmware attacks and their countermeasures. Firmware attacks, categorized as availability-targeting threats [15], typically follow a three-phase methodology: (1) reverse engineering to deduce firmware update validation protocols; (2) identification of exploitable weaknesses enabling firmware modification; and (3) deployment of malicious firmware samples for execution on compromised PLCs.

While existing detection mechanisms such as Aye [16] employ JTAG-based memory comparison to effectively identify conventional firmware tampering, emerging attack vectors challenge such approaches. Recent research has demonstrated the AFZA (Autonomous Firmware Zombie Attack) [17], a sophisticated attack methodology that combines firmware manipulation, botnet propagation, and malware injection. This hybrid attack vector operates without requiring active network connectivity and leaves minimal forensic traces, achieving both substantial operational disruption and evasion of traditional detection systems.

The persistent challenge lies in the reactive nature of security updates. Despite continuous advancements in defensive technologies, novel attack patterns inevitably emerge, creating a perpetual latency between threat evolution and protective measures. This phenomenon underscores the limitations of post-compromise security strategies in industrial control systems.

1.4. Redundancy and Fault Tolerance Approaches

Redundancy technology serves as a critical approach for enhancing system reliability and fault tolerance, where diversified fault-tolerant capabilities can be endowed to PLCs depending on their resource characteristics and scale. At the system level, redundancy is typically achieved through constructing multiple redundant PLC instances [18,19,20,21]. At the component level, redundancy implementation focuses on critical elements within PLCs, including control logic programs [22], firmware [23], and hardware configurations.

As summarized in

Table 1. A comparison of prominent defense strategies for securing PLCs.

Defense Strategy	Representative Works	Implementation Challenges	Industrial Applicability
Traditional Cybersecurity Frameworks	[4,5,6,7,8]	Rely on cryptographic algorithms, authentication protocols, and access control mechanisms.	Fundamentally incompatible with the real-time operational constraints and legacy protocol-specific requirements of PLCs.
System-Level Hardening Approach	[9,10,11,12]	Involves securing control systems that closely interact with PLCs (e.g., underlying field devices and upper-layer supervisory communication).	Suffers from inherent limitations, including dependencies on centralized architectures and a high rate of false positives.
Built-In Security Architectures	[13,14,15,16,17]	Embedding countermeasures based on known threats or attack patterns.	Protection measures inherently lag behind emerging attack methods.
Redundancy and Fault Tolerance Approaches	[18,19,20,21,22,23]	Employing redundant PLC instances or replicating critical components within a PLC.	High implementation cost, slow response times, and ineffective against common-cause failures.
MimicPLC	This paper	A Heterogeneous Multi-Core Architecture with dynamic scheduling and consensus-based output.	Offers moderate cost, rapid response, and demonstrated resilience against common-cause failures.

, each existing defense strategy has inherent limitations that motivate our proposed approach.

Redundancy techniques can be categorized into three primary types based on their implementation mechanisms and operational states: active, standby, and hybrid redundancy [24]. Active redundancy, characterized by concurrent operation of multiple redundant components with parallel task processing, employs Concurrent Duplicated Execution (CDE) combined with result voting mechanisms to enhance system reliability. This approach demonstrates strong real-time performance despite higher resource consumption, making it particularly suitable for mission-critical real-time systems such as aerospace applications and nuclear power control systems.

Among the most relevant prior works, Dai et al. [21] proposed a heterogeneous redundant architecture for industrial control system security, employing multiple discrete processor boards interconnected via external communication links. While their approach demonstrated the feasibility of heterogeneous redundancy for PLC protection, the reliance on inter-board communication introduces non-trivial latency overhead and increases the physical footprint, limiting its applicability in space-constrained industrial cabinets. Similarly, Luo et al. [22] presented a quad-redundant PLC architecture designed for cyber-resilient industrial control, achieving fault tolerance through four homogeneous or near-homogeneous processing channels with software-based voting. However, their solution operates at the software layer, resulting in millisecond-scale detection latency, and the use of similar processor cores does not fully mitigate common-cause failure risks. In contrast, MimicPLC addresses both limitations simultaneously: by integrating three instruction-set-heterogeneous cores within a single chip and performing consistency arbitration entirely in hardware, our approach achieves sub-microsecond detection latency while inherently reducing CCF susceptibility through architectural diversity.

Furthermore, redundancy techniques can be differentiated by component homogeneity into homogeneous and heterogeneous redundancy [25]. In contrast to homogeneous configurations, heterogeneous redundancy not only significantly reduces Common Cause Failure (CCF) risks but also substantially diminishes the reusability of attack vectors and exploit results. This dual advantage enables superior performance in both functional safety and cybersecurity domains [26].

1.5. Research Gap and Contributions

Despite significant advances in each of the four research trajectories discussed above, no existing solution simultaneously satisfies the following requirements for next-generation secure PLCs: (1) chip-level integration (rather than multi-chip discrete solutions); (2) hardware-level real-time arbitration with sub-microsecond detection latency; (3) intrinsic/endogenous security rather than perimeter-based or reactive defense; and (4) compatibility with existing industrial standards including IEC 61131-3 (IEC 61131-3:2013; Programmable Controllers—Part 3: Programming Languages. International Electrotechnical Commission: Geneva, Switzerland, 2013). This study aims to bridge this gap by proposing MimicPLC, which is inspired by the cyberspace mimic defense theory [27].

The key novelties of MimicPLC are twofold. First, unlike prior heterogeneous redundancy solutions that rely on multiple discrete chips connected via external interconnects, we integrate three instruction-set-heterogeneous cores (ARM Cortex-M3, MIPS microAptiv UC, RISC-V T-Head E906) into a single SoC (ESC0830). This chip-level integration fundamentally reduces arbitration latency by eliminating off-chip communication overhead. Second, we propose a purely hardware-based mimic scheduling subsystem that performs transaction-level consistency checks on the AHB-Lite bus. This hardware arbitration achieves threat perception within 73 clock cycles (~4562.5 ns at 16 MHz), a detection speed unattainable by software-based voting schemes that typically operate at millisecond scale. Compared to multi-chip TMR approaches, our integrated design reduces physical footprint by over 60% and eliminates inter-chip communication delays, as detailed in Section 3.3.2.

2. Overall Architecture of MimicPLC

2.1. Components of MimicPLC

Before describing the components, we clarify the terminology used in this paper. ESC0830 is the model number of the integrated heterogeneous multi-core security controller chip. MimicMCU refers to the mimic scheduling hardware subsystem within the ESC0830 chip, responsible for bus-level consistency checking and arbitration. MimicPLC denotes the complete PLC system built upon the MimicMCU chip, including peripheral modules (power, AIO, DIO, communication) and the software stack.

MimicPLC comprises five main components: the MimicMCU chip, power module, analog input/output module (AIO), digital input/output module (DIO), communication module, along with the associated software as shown in Figure 1.

The MimicMCU chip serves as the core component, responsible for logical control, data acquisition and output, and communication management. The power module provides the various voltage levels required by the MimicPLC. The AIO module collects and outputs analog signals from external devices such as temperature sensors. The DIO module collects and outputs discrete signals, such as the status of relay contacts. The communication module primarily handles the networking of the MimicPLC, enabling it to form a networked control system together with numerous other industrial control devices.

The MimicPLC software consists of three parts: heterogeneous CPU compilation toolchains, an integrated development environment (IDE) based on VSCode, and firmware including the boot program, logic control program, and communication program.

2.2. Dynamic Defense Process of MimicPLC

The dynamic defense process of MimicPLC comprises four key stages as shown in Figure 2. First, it identifies anomalies in the output results generated by heterogeneous CPUs, thereby perceiving the threats to the system. Secondly, based on predefined mimicry defense strategies, it determines appropriate actions to handle the current output results and addressing the abnormal CPU. Thirdly, it delivers a trustworthy result according to the decision while simultaneously applying corrective measures to the faulty CPU to prevent further degradation. Finally, feedback is obtained from subsequent mimic judgment results and the states of the heterogeneous CPU executors after cleanup and restoration. This feedback is then used to enhance the perception of the security and safety posture of MimicPLC’s.

To maintain compatibility with the IEC 61131-3 standard, each functional CPU internally executes its control logic program using a cyclic scanning method. However, at the system level, real-time interrupt handling is achieved through a dedicated Interrupt Agent Module within the MimicMCU. This hardware module synchronously distributes external interrupt signals to all three functional CPUs, enabling them to process interrupts concurrently and present a unified real-time response to the external world.

2.3. Flowchart of Attack Scenario Response

When a single CPU processor in the MimicPLC suffers from vulnerability, backdoor, or anomaly, its behavior diverges from that of the other two CPU executors. If the compromised CPU does not access the peripherals, the external remains unaffected. However, if it accesses the peripherals, different peripheral bus transmission transactions will be generated for the mimic schedule subsystem. Consequently, the mimic schedule subsystem conducts a majority vote on the three sets of peripheral-access requests. It outputs consistent results, issues an alarm for any inconsistency, and takes actions according to the mimic scheduling strategy.

As shown in Figure 3, the entire response process for an attack scenario consists of four steps.

• Step 1: CPU2 is attacked via a vulnerability or backdoor, or experiences an anomaly. During a control cycle, it executes an incorrect peripheral access instruction, while CPU0 and CPU1 execute the correct peripheral access instructions.
• Step 2: The peripheral access instructions from all three CPUs are sent to the mimic schedule subsystem, where a consistency check is performed by the arbiter.
• Step 3: The consistent peripheral instructions from CPU0 and CPU1 are successfully forwarded to the peripheral controller. Meanwhile, the incorrect instruction from CPU2 is blocked, and the cleanup and restoration module within the mimic schedule subsystem is notified. Until the cleanup and recovery process is completed, the MimicMCU chip schedules the remaining two heterogeneous CPUs to operate under the control of the mimic schedule subsystem, causing Mimic-PLC to enter a dual-module heterogeneous redundancy state.
• Step 4: The cleanup and restoration module cleans and restores the stack, registers, etc., of CPU2 according to the mimic scheduling strategy, returning it to a normal state. This entire cleanup and recovery process is orchestrated by the mimic scheduler. Based on actual measurements, the cleanup and recovery process for a single executor can be completed within 10 ms.

2.4. Heterogeneous Multi-Core Adjudication Mechanism of MimicPLC

The heterogeneous multi-core adjudication mechanism of MimicPLC primarily relies on the MimicMCU chip as shown in Figure 4. The chip incorporates three heterogeneous CPU cores: MIPS Microaptiv UC, ARM Cortex-M3, and RISC-V T-Head E906. Due to differences in the instruction sets, architectures, and interfaces of these three heterogeneous redundant processors, cycle-by-cycle comparison of their output interfaces is not feasible for consistency verification. To address this, a lightweight mimic scheduling IP is integrated into the chip to perform consistency checks on the system bus. This verification is achieved through a loosely coupled, transaction-level comparison on the bus.

It examines only the transactions generated when processors access peripherals, thereby preventing the propagation of attacks or errors to devices outside the processors. Through this mechanism, the mimic scheduler can detect abnormal peripheral access requests from heterogeneous executors, thereby identifying the presence of unknown vulnerabilities, backdoors, or faults.

Simultaneously, based on the consistency check results, the mimic scheduling IP cleans and restores abnormal CPUs to return them to a normal state. Since the arbitration system is implemented in hardware circuitry, the entire arbitration process requires only tens of AHB-Lite bus clock cycles, enabling completion with sub-microsecond latency.

Regarding the security of the policy CPU itself (the RISC-V T-Head E906 core), we note the following safeguards. First, the core arbitration functionality—including the multi-core request comparators, timeout counters, and interrupt controllers—is implemented in dedicated hardware within the Checker module, not in software running on the policy CPU. This hardware logic is inherently resistant to software-based attacks. Second, the firmware executed by the policy CPU is stored in write-protected memory with hash-based integrity verification, preventing unauthorized modification. Third, in the event of a policy CPU failure, the system can fall back to a “bypass mode,” where the three functional CPUs directly access peripherals without consistency checking, sacrificing security but preserving basic PLC functionality. Fourth, future work will explore lightweight redundancy for the policy CPU itself, such as a dual-policy-core backup configuration. These measures collectively mitigate the risk posed by the policy CPU as a single point of failure.

3. Hardware Implementation

To achieve the functionality of a secure PLC system, the hardware design centers around a heterogeneous multi-core processor, integrated with a mimic scheduling subsystem and an AHB-Lite bus, to establish an efficient data transmission and real-time voting mechanism. This system is capable of detecting and responding to unknown attacks through nanosecond-scale arbitration latency, significantly enhancing the system’s security and reliability.

3.1. Hardware Design

3.1.1. Requirements Analysis

The secure PLC system must possess the following functionalities and characteristics:

Functional Requirements:

• Support for analog input/output, digital input/output, CAN, and RS485 communication.

Security Requirements:

• Adoption of an intrinsic security architecture, integrating heterogeneous redundant multi-core processors and a mimic scheduling subsystem to achieve active defense capabilities.

Performance Requirements:

• Nanosecond-scale arbitration latency for threat detection, high-precision ADC/DAC, isolation protection, and support for multi-node communication to meet the stringent demands of industrial environments.

3.1.2. Chip Selection

The security functions of the system are implemented based on a heterogeneous multi-core arbitration framework. As the core component of the PLC, the CPU is responsible for critical tasks such as system control, data processing, and logic control. Therefore, a heterogeneous multi-core processor and abundant interface resources are required. This design selects the embedded low-power intrinsic security controller chip ESC0830, which features the following key characteristics:

• Heterogeneous Multi-core: Integrates ARM Cortex-M3, MIPS microAptiv UC, and RISC-V E906 cores.
• Rich Interfaces: Provides 8 UART interfaces, 2 CAN controllers, and various I/O resources.
• Mimic Scheduling: Incorporates a mimic scheduling subsystem, supporting multi-redundancy voting mechanisms to ensure high system reliability.

3.1.3. Resource Allocation

To fully leverage the performance of the ESC0830 chip and meet the real-time, reliability, and security requirements of the secure PLC, the resource allocation is as follows:

• Mimic Scheduling Subsystem: Responsible for consistency checks of the outputs from heterogeneous cores.
• High-precision ADC/DAC: Connected via GPIO-simulated SPI bus, with GPIO pins allocated for SCLK, MISO, MOSI, and chip select signals to enable efficient acquisition and output of analog data.
• Digital Output: GPIO pins are allocated for relay driver circuits to implement digital output functionality.
• Digital Input: Connected to an industrial digital input signal level converter via GPIO-simulated SPI bus, with GPIO pins allocated for SCLK, MISO, MOSI, and chip select signals to enable efficient acquisition of digital data.
• Communication Interfaces: Independent UART and CAN pins are allocated to ensure communication quality.

3.2. Heterogeneous Core Voting Based on AHB Bus

In the intrinsic security controller chip, the mimic scheduling subsystem is connected to three heterogeneous processors (ARM, MIPS, and RISC-V) through three sets of AHB-Lite slave interfaces. It compares the AHB-Lite transactions initiated by the processors when accessing peripherals to ensure consistency in their access requests. If the comparison results are consistent, it indicates that the access requests are identical, and the peripheral operation can be safely executed. If inconsistencies are detected, an error handling mechanism is triggered.

This design innovatively adopts a heterogeneous core voting mechanism based on the AHB bus, leveraging AHB bus technology and related techniques to achieve low-latency arbitration, significantly enhancing system performance.

The key technologies involved in this design include:

1. Parallel Comparison Logic: A comparator with parallel comparison logic supports a 32-bit data width and can simultaneously compare the outputs of three cores (ARM, MIPS, and RISC-V). It completes the comparison of address, transfer type, transfer size, and write data within a single clock cycle. This effectively avoids the delays associated with serial comparison, ensuring real-time performance.

2. Real-time Error Detection: During the comparison process, if inconsistencies are detected in the outputs of the three cores, the error detection mechanism is immediately activated to prevent error propagation.

3. Fast Response Mechanism: When the mimic scheduling subsystem detects an error, it immediately sends an interrupt signal to the policy CPU. The policy CPU then executes predefined error handling operations based on the configuration. This ensures system security by enabling rapid response to anomalies.

4. Priority Management: A priority management mechanism assigns the highest priority to comparison and voting operations, ensuring timely execution of critical tasks. A priority arbiter prevents low-priority tasks from preempting resources, reducing delays.

5. Real-time Scheduling Algorithm: An efficient real-time scheduling algorithm combines time-sliced round-robin and priority preemption mechanisms to optimize task execution order. It ensures that comparison and voting operations are completed within tens of nanoseconds while significantly reducing task waiting time.

These technologies collectively provide a robust foundation for the secure and reliable operation of the PLC system, meeting the stringent requirements of industrial applications.

3.3. Performance Analysis and Comparison

3.3.1. Arbitration Latency Analysis

The arbitration latency is a critical metric for evaluating the real-time performance and security of the intrinsic security PLC system. This section provides a detailed analysis of the arbitration latency of the mimic scheduling subsystem based on the operating frequency of the AHB-Lite bus (120 MHz, clock cycle of 8.33 ns), considering practical design factors. The analysis includes FIFO queue latency and comparison operation latency.

1. 

FIFO Queue Latency Analysis

The FIFO queue is used to buffer AHB-Lite transactions from the three heterogeneous processors. Its latency primarily includes read/write operation delays and additional delays introduced by the queue’s state (full/empty).

The internal FIFO and synchronization logic of the scheduler also isolate potential timing violations (e.g., HREADY wait states) that might be caused by a compromised CPU, ensuring the integrity of the arbitration process and the AHB-Lite bus timing.

(1)

Read/Write Operation Latency

• Typical Case: The read/write operations of the FIFO queue are usually completed within 1 clock cycle, taking 8.33 ns (based on a 120 MHz clock frequency).
• Practical Considerations: In actual designs, read/write operations may be affected by factors such as bus arbitration or priority management, potentially introducing additional wait cycles.

As a result, the latency of read/write operations may increase to 10–15 ns.

(2)

Impact of Queue State on Latency

• FIFO Queue Full: When the FIFO queue is full, write operations must wait for available space, typically introducing an additional delay of 1–2 clock cycles (8.33 ns to 16.66 ns).
• FIFO Queue Empty: When the FIFO queue is empty, read operations must wait for new data to arrive, which may also introduce an additional delay of 1–2 clock cycles (8.33 ns to 16.66 ns).

(3)

Total FIFO Queue Latency

• Best-case Scenario (FIFO neither full nor empty): The total latency for read/write operations is 16.66 ns (2 clock cycles).
• Worst-case Scenario (FIFO full or empty): The total latency may increase to 33.32 ns (4 clock cycles).

2. 

Comparison Operation Latency Analysis

• The comparison operation is the core function of the mimic scheduling subsystem. Its latency primarily includes combinational logic delay and routing delay.

(1)

Combinational Logic Delay

• Comparison Operations: The comparison operation includes the comparison of address (HADDR), transfer type (HWRITE), transfer size (HSIZE), and write data (HWDATA).
• 32-bit Comparator Delay: For a 32-bit comparator, the combinational logic delay typically ranges from1 to several clock cycles. Based on the process characteristics of the intrinsic security controller chip, the estimated combinational logic delay is 5 ns to 20 ns.
• Parallel Operation: Multiple comparators can operate in parallel, ensuring that the total combinational logic delay does not increase significantly.

(2)

Routing Delay

• Global Interconnect Delay: In the process technology of the intrinsic security controller chip, the global interconnect delay is 10 ps/mm to 50 ps/mm.
• Chip Internal Routing Length: Since the internal routing length of the chip is typically short (less than 1 cm), the routing delay is no more than 1 ns.

(3)

Total Comparison Operation Latency

• Total Latency = Combinational Logic Delay + Routing Delay.
• Worst-case Scenario: The total latency is approximately 21 ns (20 ns for combinational logic delay + 1 ns for routing delay).

3. 

Total Arbitration Latency

The total arbitration latency includes FIFO queue latency and comparison operation latency:

• Best-case Scenario:

  ○

  FIFO queue latency: 16.66 ns.

  ○

  Comparison operation latency: 21 ns.

  ○

  Total Latency: 37.66 ns.

• Worst-case Scenario:

  ○

  FIFO queue latency: 33.32 ns.

  ○

  Comparison operation latency: 21 ns.

  ○

  Total Latency: 54.32 ns.

Through a detailed analysis of FIFO queue latency and comparison operation latency, it is evident that even in the worst-case scenario, the total arbitration latency of the AHB-Lite bus-based mimic scheduling subsystem is 54.32 ns. This performance metric demonstrates that the intrinsic security controller chip can complete the output comparison of heterogeneous cores at the nanosecond scale, enabling the system to detect anomalies with extremely low latency. This meets the stringent real-time and security requirements of PLC systems.

3.3.2. Analysis and Comparison of Different Hardware Solutions

Heterogeneous multi-core arbitration can be implemented in two main hardware approaches: a conventional multi-chip solution or the integrated intrinsic-security controller chip proposed here. As compared in

Table 2. Comparison of different hardware solutions for heterogeneous multi-core arbitration.

Metric	Integrated Intrinsic-Security Controller Chip (Proposed Design)	Conventional Multi-Chip Discrete Solution
Area	Chip-level integration significantly reduces the physical footprint, facilitating device miniaturization.	Multiple discrete chips require extra PCB area and inter-chip interconnections, resulting in a larger overall layout.
Power	Lower static power due to functional consolidation and resource sharing. Better dynamic power management through efficient scheduling.	Higher static power consumption due to more components. Higher dynamic power consumption caused by coordination and communication overhead.
Layout complexity	Single-chip integration leads to a compact layout, simpler routing, lower EMI risk, and higher reliability.	Multi-chip layout is more complex, requiring careful interface design to maintain signal integrity, and introduces challenges such as delay, noise, and thermal management.
Estimated BOM Cost	Moderate (single chip + PCB). By eliminating multiple chip packages, external interconnects, and additional PCB layers, the integrated design is estimated to achieve approximately 40–50% BOM cost savings compared to a discrete multi-chip implementation of equivalent functionality.	Higher (multiple discrete chips + larger multi-layer PCB + inter-chip connectors and level-shifting circuitry), resulting in an estimated 40–50% cost premium over an equivalent integrated solution.
Overall performance	Lower power, smaller area, simpler design, and higher performance (benefiting from on-chip interconnects and optimized scheduling).	Higher power, larger area, more complex design, and lower performance (limited by external connections and scheduling overhead).

, a comparative analysis across area, power consumption, layout complexity, BOM cost, and overall performance highlights the advantages of the integrated design.

In summary, the intrinsic-security controller chip outperforms the conventional multi-chip approach in all key metrics, proving more suitable for practical industrial deployment.

4. Experimental Design

4.1. Terminology

In this experiment, several key concepts are defined to establish a clear understanding of the system. The “functional CPU” refers to independent cores that execute application instructions. The specifications and roles of each core are listed in

Table 3. Specifications and roles of CPU cores in MimicPLC.

Core Designation	Core Type	Primary Responsibility
Functional CPU0	MIPS microAptiv UC	Execute control logic (MIPS ISA)
Functional CPU1	ARM Cortex-M3	Execute control logic (Thumb-2 ISA)
Functional CPU2	RISC-V T-Head E906	Execute control logic (RV32IM ISA)
Policy CPU	RISC-V T-Head E906	Dynamic arbitration, cleanup, alert logging

. Each functional CPU, along with its private memory (FLASH and SRAM), forms an “execution body”—a physically isolated subsystem designed to prevent the propagation of any single point of failure.

These are complemented by the “policy CPU,” which is implemented using the RISC-V T-Head E906 core and handles critical safety operations such as dynamic arbitration, exception cleanup, and alert log generation. The system also includes a scheduling subsystem that lies between the heterogeneous execution bodies and the bus matrix. This subsystem integrates a hardware-level Checker module with the policy CPU to enable coordinated control among the diverse cores. The Checker module, equipped with multi-core request comparators, timeout counters, and interrupt controllers, continuously monitors AHB bus transactions and blocks any abnormal peripheral access.

A notable security challenge addressed in this setup is the “single execution body unknown vulnerability backdoor attack.” This refers to a zero-day attack targeting a specific functional CPU—such as one involving a memory overflow or instruction injection—where the attack mechanism remains unclear and can only be inferred from abnormal behaviors like AHB data inconsistencies or transmission timeouts. In response, the system employs a “cleanup and recovery” process whereby the scheduling subsystem forcefully restarts the affected functional CPU, reloads the original firmware, and restores its tasks. The duration from the detection of an abnormality in a functional CPU until the MimicPLC regains stable output is defined as the cleanup and recovery time.

The heterogeneous redundancy design fundamentally reduces the risk of Common Cause Failures (CCF), making simultaneous successful attacks on multiple, diverse CPUs significantly more difficult. In the event that multiple functional CPUs are compromised and detected (output inconsistencies), the system will escalate to a higher fault level, potentially initiating a controlled, full-system safety reset. To further mitigate the risk of stealthy, coordinated attacks that evade immediate detection, the system incorporates proactive defense mechanisms, such as periodically and randomly resetting and verifying one of the functional CPUs, to disrupt potential persistent attack vectors.

It should be acknowledged that the current detection mechanism assumes that attacks manifest as divergent AHB bus transactions. A potential limitation is the scenario where a sophisticated attacker exploits a common vulnerability shared across all three cores (e.g., a flaw in the common AHB-Lite bus protocol or a shared library component), causing them to generate identical malicious transactions that would pass the consistency check. To mitigate this risk, the system incorporates proactive defense mechanisms: (1) periodic random reset and verification of one functional CPU to disrupt persistent attack vectors, as noted above; (2) the policy CPU can be configured to perform long-term behavioral pattern analysis using statistical methods. Nevertheless, detection of covert attacks that produce consistent malicious behavior across all cores remains an open challenge and is identified as a key direction for future work (see Section 7).

4.2. Test Environment Topology

As depicted in Figure 5, the test topology is composed of several hardware and software components, enabling comprehensive validation of functionality, safety, and performance. The hardware setup includes the development board itself—which integrates the MimicMCU chip and its peripheral resources—a PC running a customized IDE environment (capable of multi-core heterogeneous compilation), a serial terminal, and test scripts. In addition, a protocol analyzer (a ZLG USBCAN-2E-U interface card capturing CAN bus communication frames at 1 Mbps) is used to analyze data integrity, while a Tektronix MS044 oscilloscope, sampling at 6.25 GS/s, monitors GPIO level transitions to accurately quantify cleanup and recovery delays and signal jitter.

On the software side, the heterogeneous compilation toolchains are utilized to generate independent executable files tailored to the different CPU cores (MIPS, ARM, and RISC-V). Moreover, an attack simulation framework—implemented through C language test scripts—triggers vulnerability backdoor attacks and records any abnormal behaviors. The overall testing process involves compiling and burning the source code into separate binary files for the three heterogeneous CPUs, which are then loaded into each CPU’s private Flash area via a serial terminal. Once the development board is powered up, control data is output through UART0 while security logs are captured on UART2. Finally, the test program is executed, and data is collected using the protocol analyzer, oscilloscope, and serial terminal.

4.3. Functional Verification

To assess the practical reliability of MimicPLC, functional validation is carried out under industrially relevant conditions. The following tests simulate real-world applications across various domains, ensuring the system’s robustness in digital control, analog signal processing, and industrial network communication.

• Digital Peripherals: High-Reliability Relay Control

Test Case: The LED indicator connected to GPIOF_PIN1 is driven to simulate the control of an industrial valve in a chemical plant scenario.

Real-World Application: In petrochemical installations, MimicPLC controls the on/off state of explosion-proof relays through its digital output module. This ensures that emergency shut-off valves activate and lock when pipeline pressure exceeds safe limits. During testing, the precise switching of the LED verified the integrity of the I/O port signals, demonstrating reliable digital control.

2.

Analog Peripherals: Precision Sensor Signal Acquisition

Test Case: A sliding resistor (R59, adjustable from 10 Ω to 2 MΩ) is used to modulate the input signal, which is then sampled by ADC0 and converted into a temperature reading, simulating the behavior of a temperature sensor.

Real-World Application: In metallurgical heating furnace temperature control systems, MimicPLC leverages a 12-bit ADC to continuously sample thermocouple signals in real time. The collected data is processed using PID and other control algorithms to dynamically regulate heating power. During testing, the ADC operated with a 30 MHz clock, and the UART output reflected real-time changes in the sampled values, accurately tracking variations in the simulated signal.

3.

Communication Peripherals: Real-Time Industrial Network Connectivity

Test Case: Data frames are cyclically transmitted over the CAN bus, specifically frame ID 0x26 with data 0x12345678 and frame ID 0x27 with data 0x87654321. The transmitted frames are then analyzed using a CAN interface card to verify data integrity.

Real-World Application: In an automotive welding production line, MimicPLC functions as the master node of a CAN network, coordinating multiple welding robots to operate in sync. During testing, the CAN protocol analyzer successfully captured all transmitted frames, achieving a 100% transmission success rate—meeting the reliability requirements of industrial conditions.

4.4. Security Testing

As a core innovation of intrinsically secure PLCs, MimicPLC employs a dynamic randomized attack surface through its heterogeneous architecture. This section follows the IEC 62443 industrial security standard, selecting four typical industrial control attack vectors for empirical analysis. These tests evaluate the system’s survivability against zero-day attacks. A formal description of each attack type is provided below.

Denial-of-Service (DoS) Attack: This attack overwhelms the target with a massive number of forged requests, exhausting system resources and rendering the PLC incapable of normal operation. In our test setup, a DoS attack on functional CPU [i] is modeled as the injection of an infinite loop instruction at a specific program counter:

PC_attack: JMP PC_attack   // Infinite loop

This causes CPU[i] to cease making legitimate peripheral access requests within the expected time window T_timeout. The system detects this by a timeout counter that triggers when t_since_last_ahb_request > T_timeout. In power grid SCADA systems, for example, a PLC must process protective relay signals within a 10 ms cycle.

Replay Attack: This attack captures and resends historical control commands, disrupting the timing logic and breaking the real-time feedback loop. Formally, a replay attack replaces the current instruction or data with a previously recorded value V_old:

HWDATA_actual(t) = HWDATA_old(t − Δ)   // where Δ > 0

The AHB-Lite consistency check detects this when HWDATA_CPU[i] is not equal to HWDATA_CPU[j]. For instance, in a chemical reactor temperature control system, the PLC dynamically adjusts heating power to maintain safe operating temperatures.

Code Injection Attack: This attack forges malicious control instructions to directly compromise physical processes. In our experiment, an “ebreak” instruction (machine code 0x9002) is injected into CPU2’s instruction stream, deliberately triggering an exception. The system detects the attack when the compromised CPU generates divergent AHB bus transactions compared to the other two cores.

Overwrite Attack: This attack alters core control parameters, causing the system to deviate from safe operating conditions while appearing normal. Formally, the attack modifies a critical parameter P at memory address A:

MEM[A] <- P_malicious, where P_malicious ! = P_legitimate

When CPU0 attempts to propagate the modified parameter via a peripheral write transaction, the AHB-Lite consistency check detects the discrepancy. For example, in an oil pipeline pressure control system, an attacker could attempt to modify the pressure threshold, leading to undetected unsafe conditions.

4.5. Fault Injection

A controlled software fault injection method was designed to validate MimicPLC’s detection and response mechanisms. This method simulates control-flow hijacking by exploiting a latent software vulnerability (e.g., pointer corruption) in one CPU.

Fault injection is orchestrated via three dedicated GPIO output pins. One pin serves as an INJECT_TRIGGER, while two others encode the TARGET_CPU, specifying which functional core is to be compromised.

When triggered, a non-maskable interrupt is generated and routed through the External Interrupt Controller under the control of the mimic scheduler as shown in Figure 6. The scheduler delivers the interrupt nearly simultaneously to the currently online functional CPUs. All cores execute the same Interrupt Service Routine (ISR). Within this routine, the designated target CPU executes a malicious payload that corrupts a critical function pointer in its private SRAM, redirecting execution to a malicious routine.

This forced divergence causes the compromised CPU to generate different peripheral access requests on the AHB-Lite bus compared to the others. The hardware-based mimic scheduling IP detects this inconsistency in real-time, triggering the anomaly response and recovery protocol described in Section 2.4. This method provides a repeatable and observable validation of the system’s ability to contain control-flow hijacking attacks.

4.6. Defense Effectiveness Evaluation

To comprehensively assess the defensive capabilities of MimicPLC against cyberattacks, this section analyzes its performance from two key aspects: attack response time and system reliability. When an attack occurs, the system must quickly detect anomalies and implement effective recovery measures. Therefore, two critical real-time indicators are evaluated: perception latency ($t_{perception}$), which measures the time from the attack’s initiation to its detection, and recovery latency ($t_{recover}$), which quantifies the time required for the system to mitigate the attack and resume normal operation.

5. Experimental Setup

5.1. Simulation Tools

The experiment utilized Synopsys’ VCS and Verdi simulation platform to conduct full-process RTL-level verification of the MimicPLC system. As a digital circuit simulation tool, VCS compiled the RTL code into an executable program, which was then stimulated by a 16 MHz clock to simulate chip operation, generating high-precision timing waveforms in FSDB format. Meanwhile, Verdi served as a debugging tool, providing waveform visualization, signal tracing, and finite state machine (FSM) transition analysis. The simulation was executed on a host equipped with an Intel Core i9-10900K processor (3.7 GHz, 64 GB RAM) running CentOS 7.2, ensuring computational efficiency for large-scale logic simulation.

5.2. State Machine

The system’s fault-tolerant logic, illustrated in Figure 7, is driven by a dynamic state machine, transitioning through the following key states. The finite state machine has been validated through comprehensive RTL simulation, covering all 14 states and all possible transition paths. Functional coverage analysis confirms 100% state coverage and 100% transition coverage across the simulated attack scenarios.

IDLE (State 0): After power-up, the system completes a hardware self-check and unconditionally transitions to the CHECKER state.

CHECKER (State 1): Continuously monitors AHB requests from the three functional CPUs. If an anomaly is detected, the system transitions to ALL_ERROR, S0_ERROR, S1_ERROR, or S2_ERROR accordingly, isolating the faulty core and initiating a recovery process. Depending on the policy CPU’s configuration, the system may also transition to CTRL_MODE.

S[x]_ERROR (States 4, 7, 10): When the execution result of $CPU\left[x\right]$ fails validation (indicated by an increment in the $\mathrm{s}\left[x\right]\text{\_}\mathrm{e}\mathrm{r}\mathrm{r}\text{\_}\mathrm{c}\mathrm{n}\mathrm{t}$ signal), the system transitions from the CHECKER state to this error state. In this state, the system accesses peripherals based on transaction data from the remaining two functional CPUs. After completing the current transaction, the system exits this state. Here, $\left[x\right]$ represents an element of the set {0,1,2}, corresponding to the MIPS Aptiv UC core, ARM Cortex-M3 core, and RISC-V T-Head E906 core, respectively.

WAIT_S[x]_RESTORE (States 5, 8, 11): After completing a peripheral transaction in S[x]_ERROR, the system transitions to this state. Here, the policy CPU issues a reset command (cpu[x]_reset signal set to 1) to trigger a forced reboot of the faulty core. Once $CPU\left[x\right]$ completes its reset and firmware reload, the system exits this state.

WAIT_S[{0,1,2}-{x}]_EVENT_END (States 6, 9, 12): In this state, $CPU\left[x\right]$ remains idle, while the remaining two functional CPUs continue execution and output results for peripheral access. If the results from the two healthy CPUs mismatch, the system transitions to the ALL_ERROR state; otherwise, it continues execution until the current task is completed, then exits this state.

S[{0,1,2}-{x}]_SAVE_CONTEXT (States 26, 27, 28): Once the ongoing task is completed, the two functional CPUs save their execution context and report to the policy CPU. The system then transitions back to CHECKER, while the policy CPU instructs $CPU\left[x\right]$ to resume execution from the last aligned position.

CTRL_MODE (State 13): The policy CPU takes exclusive control over peripheral access, issues an alert, and subsequently transitions back to the previous state.

5.3. Defense Effectiveness Metrics

The real-time performance of the system is evaluated based on two key latency metrics: attack perception latency and attack recovery latency.

The attack perception latency ($t_{perception}$) measures the time elapsed from the moment an attack-related $\mathrm{s}\left[x\right]\text{\_}\mathrm{a}\mathrm{h}\mathrm{b}\text{\_}\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{o}$ request first appears to the point when the system detects the anomaly and increments the corresponding $\mathrm{s}\left[y\right]\text{\_}\mathrm{e}\mathrm{r}\mathrm{r}\text{\_}\mathrm{c}\mathrm{n}\mathrm{t}$ counter. Here, [y] belongs to the same set as [x], meaning it can either be the same CPU or a different one. This metric reflects the system’s responsiveness in identifying malicious or faulty transactions in real-time.

The attack recovery latency ($t_{recover}$) quantifies the time interval from the moment the error counter $\mathrm{s}\left[x\right]\text{\_}\mathrm{e}\mathrm{r}\mathrm{r}\text{\_}\mathrm{c}\mathrm{n}\mathrm{t}$ increments until the state machine transitions into WAIT_S[{0,1,2}-{x}]_EVENT_END. At this stage, the system has successfully isolated the faulty core and initiated a degraded execution mode, allowing the remaining healthy cores to continue operation. This metric is crucial for assessing the system’s capability to contain and mitigate faults while maintaining functional integrity.

6. Experimental Results

6.1. DoS Attack

To simulate a DoS attack scenario, the experiment injects an infinite loop into CPU0 (MIPS), monopolizing its computational resources as shown in Figure 8. This mimics a scenario where an attacker floods the system with malicious packets, causing real-time task blocking.

At 52.1 ms, an infinite loop task was injected into Functional CPU0. The system detected the anomaly at 56.3 ms when the timeout threshold (set to 0x10000 clock cycles in the experiment) was triggered, leading to an increment in the $\mathrm{s} \left[0\right]\text{\_}\mathrm{e}\mathrm{r}\mathrm{r}\text{\_}\mathrm{c}\mathrm{n}\mathrm{t}$ counter. The Strategy CPU immediately isolated Functional CPU0, initiated its cleanup and recovery process, and awaited its readiness. At 62.0 ms, the system switched to a dual-core redundancy mode using CPU1 and CPU2 to continue executing subsequent tasks. By 65.0 ms, the ongoing task had been completed, and Functional CPU0 was ready for reintegration. At 66.9 ms, CPU0 resumed execution at an aligned position, restoring the system to triple modular redundancy.

The complete state transitions during this process were: CHECKER → S0_ERROR → WAIT_S0_RESTORE → CTRL_MODE → WAIT_S0_RESTORE → WAIT_S12_EVENT_END → S12_SAVE_CONTEXT → CHECKER.

The experimental results confirm that the secure PLC successfully detected the DoS attack. During the recovery phase, it maintained system operation in dual-redundancy mode and seamlessly transitioned back to triple-redundancy when appropriate.

6.2. Replay Attack

To simulate a replay attack as shown in Figure 9, the experiment inserts previously recorded heating commands into the instruction stream of CPU1 (ARM). This bypasses the normal temperature control logic, potentially overheating the reactor and triggering an emergency shutdown.

At 52.4 ms, Functional CPU1 was subjected to a replay attack, attempting to resend the previous heating power value of “55.” This caused the AHB request to fail the system’s consistency check. The Strategy CPU commanded CPU1 to undergo cleanup and recovery while awaiting reintegration. From 56.5 ms onward, the other two CPUs continued processing tasks until 60.5 ms, when CPU1 was deemed ready. CPU1 then resumed execution from an aligned position, and the system restored triple redundancy at 63.8 ms.

From the state machine (cur_state signal), the sequence of state transitions was as follows: CHECKER (state 1) → S1_ERROR (state 7) → WAIT_S1_RESTORE (state 8) → CTRL_MODE (state 13) → WAIT_S1_RESTORE (state 8) → WAIT_S20_EVENT_END (state 9) → S20_SAVE_CONTEXT (state 27) → CHECKER (state 1). Between 52.5 ms and 53.7 ms, the system entered CTRL_MODE (state 13), during which the Strategy CPU exclusively accessed peripherals to issue an alert.

The experiment demonstrated that the secure PLC successfully detected the replay attack, prevented outdated data from participating in decision-making, and triggered online cleanup of the compromised execution unit.

A precise measurement under a 16 MHz clock frequency revealed that the attack perception latency—measured from the arrival of the last AHB request (s0_ahb_info) at the yellow cursor mark to the detection of the CPU1 fault (marked by the white marker and the update of s1_error_cnt)—was exactly 62.5 ns, which corresponds to one clock cycle of the 16 MHz reference clock as shown in Figure 10. This latency scales linearly with the system clock frequency; therefore, at commonly used industrial MCU frequencies of 80 MHz and 120 MHz, the equivalent perception latency would be approximately 12.5 ns and 8.33 ns, respectively.

6.3. Code Injection Attack

In this experiment, an “ebreak” instruction is injected into CPU2 (RISC-V), deliberately triggering an exception to simulate an attacker’s attempt to halt or disrupt execution as shown in Figure 11.

At 52.4 ms, Functional CPU2 experienced a code injection attack. The pad_iahbl_hrdata signal, which represents the 32-bit read data bus of CPU2’s AHB, contained the machine code 0x9002 in its lower 16 bits—corresponding to the ebreak instruction. This triggered an exception in the RISC-V core, causing the exception handler to generate abnormal AHB requests (CPU2 attempting to access 0x400c02c, while the other two CPUs accessed 0x4005d008). This discrepancy failed the system’s consistency check, prompting the Strategy CPU to command CPU2 to undergo cleanup and recovery. By 57.3 ms, the remaining two CPUs continued executing tasks, and by 60.6 ms, CPU2 was ready. The system restored triple redundancy at 63.9 ms.

The experiment confirmed that the secure PLC successfully detected the injection attack. By leveraging the instruction set asymmetry among ARM (Thumb-2), RISC-V (RV32IM), and MIPS (microAptiv UC), the system effectively prevented cross-core execution of injected malicious code.

6.4. Overwrite Attack

To test an overwrite attack scenario, the experiment manipulates the pressure setpoint stored in public SRAM by CPU0 (MIPS) and observes whether the system’s data consistency verification mechanism detects the tampering as shown in Figure 12.

At 52.2 ms, Functional CPU0 suffered a memory overwrite attack, attempting to modify a core parameter stored at address 0x20000004 from 1000 to 234. This action violated the system’s consistency check, prompting the Strategy CPU to initiate cleanup and recovery of CPU0. From 58.0 ms, the other two CPUs continued execution, and by 61.3 ms, CPU0 was ready. CPU0 resumed execution from an aligned position at 63.2 ms, restoring triple redundancy. The state transitions followed the same pattern as in the DoS attack scenario.

The experiment confirmed that the secure PLC successfully detected the overwrite attack, safeguarded legitimate parameters from corruption, and flagged CPU0 as an abnormal node.

6.5. Defense Effectiveness

To further evaluate the system’s resilience, 100 consecutive memory overwrite attacks were conducted on Functional CPU1. Key metrics such as attack perception latency ($t_{perception}$) and attack recovery latency ($t_{recover}$) were recorded, along with attack interception rate and false positive rate as shown in Figure 13.

The measured attack perception latency ($t_{perception}$) remained constant at 4562.5 ns (73 clock cycles) across all 100 tests. This consistency is attributed to the fact that all operations, from receiving the s1_ahb_info request to incrementing s1_err_cnt, were handled purely by hardware logic.

The measured attack recovery latency ($t_{recover}$) followed the distribution as shown in Figure 14, with an average of 4.0358 ms. The two most frequently occurring values were 4.03613 ms and 4.0350 ms, while the maximum recovery latency was 4.0547 ms, well within the IEC 61131-3 real-time threshold of 10 ms. Across all 100 trials under the evaluated attack conditions (DoS, replay, code injection, and overwrite), the attack interception rate was 100%, with no successful attacks detected.

The variations in recovery latency stem from software-controlled operations managed by the Strategy CPU. Additionally, optimizations such as instruction prefetching in the RISC-V T-Head E906 core resulted in fluctuations in cache behavior. As illustrated in the figure, the first recovery latency was the maximum observed value of 4.0547 ms, while subsequent recoveries stabilized around 4.03613 ms and 4.0350 ms due to repeated execution of previously cached instructions.

The maximum end-to-end delay from attack detection to complete system recovery was 9.3 ms. This design adheres to the real-time constraints typical of IEC 61131-3-based critical control applications, where a commonly adopted maximum scan cycle of 10 ms is required for hard real-time tasks in domains such as high-speed motion control and power grid protection. It should be noted that while IEC 61131-3 defines the scan cycle execution model, the specific 10 ms bound represents an industry-established practice for time-critical control loops rather than an explicit limit mandated by the standard itself. All recovery operations in our experiments, including perception and full recovery, are completed within this stringent timeframe.

It is important to discuss the implications if the recovery latency were to exceed the 10 ms bound. In a real deployment, the system employs the following safeguards. A hardware watchdog timer monitors the recovery process; if recovery exceeds a configurable threshold, the system triggers a safe state where all outputs are forced to predefined safe values, and an alarm is raised to the supervisory system. The worst-case measured recovery latency of 9.3 ms includes cold-cache conditions and maximum transaction delays, and the 95% confidence interval of recovery latency is [4.0354, 4.0363] ms, indicating that the vast majority of recoveries complete well within the bound with a 0.7 ms safety margin. For applications with stricter real-time requirements, the recovery latency can be further reduced by increasing the system clock frequency or by optimizing the firmware reload process (e.g., using DMA-based flash copying).

To place these results in context, we provide a qualitative baseline comparison with representative alternative approaches. Software-based redundancy schemes, such as application-level N-version programming or hypervisor-based replication, typically report detection latencies in the range of 1–10 ms due to software execution and inter-process communication overhead, approximately three orders of magnitude slower than the 4562.5 ns achieved by our hardware arbitration. Multi-chip TMR solutions, while capable of hardware-level voting, incur additional inter-chip communication delays (typically tens of microseconds via SPI or external bus bridges) and require significantly larger PCB area and higher BOM cost. Regarding recovery, the worst-case 9.3 ms end-to-end recovery of MimicPLC is comparable to or faster than software-based recovery mechanisms that must reinitialize an entire OS or runtime environment. A comprehensive quantitative comparison with specific commercial or academic PLC security platforms, using standardized benchmarks and identical attack scenarios, is planned as future work.

7. Conclusions

This study has presented the design, implementation, and comprehensive validation of MimicPLC, a novel security-enhanced PLC architecture that fundamentally shifts the paradigm from perimeter-based, reactive defenses to a proactive, endogenous, and dynamic security model. The core of this work is the establishment of a holistic protection system that seamlessly integrates threat perception, dynamic fault tolerance, and rapid recovery within a single heterogeneous multi-core chip, thereby resolving the longstanding conflict between real-time performance and robust security in industrial control systems.

The primary contributions of this work are twofold. First, we propose an endogenous security construction method for PLCs based on a heterogeneous multi-core processor. By integrating ARM Cortex-M3, MIPS microAptiv UC, and RISC-V E906 cores into a single system-on-chip (ESC0830), the architecture inherently introduces diversity, breaking the attack chain’s reusability across cores. Second, we propose a hardware-based threat detection mechanism via an AHB-Lite bus heterogeneous core voting scheme. The dedicated hardware scheduling IP performs real-time, transaction-level consistency checks on peripheral access requests, enabling the detection of unknown vulnerabilities, backdoors, and faults within 73 clock cycles—a detection speed unattainable in software-based or multi-chip redundant solutions.

To substantiate these innovations, we undertook significant engineering and evaluation efforts. We developed a functional FPGA prototype and a custom PCB development board, and constructed a dedicated industrial-strength testbed. This platform enabled a multi-dimensional evaluation of MimicPLC’s functionality (digital/analog/communication), performance, and security. Rigorous testing under four prevalent industrial control attack vectors—Denial-of-Service, replay, code injection, and parameter overwrite—empirically validated the system’s efficacy. The results demonstrate a 100% interception rate across the four evaluated attack vectors within our experimental testbed, with zero false positives. It should be noted that this result is specific to the set of attack scenarios and experimental conditions tested; the system’s effectiveness against other attack types remains a subject for future investigation. Critically, the system maintained continuous operation through adaptive redundancy, degrading gracefully upon attack detection. All recovery processes, with an average latency of 4.0358 ms (95% CI: [4.0354, 4.0363] ms) and a worst-case end-to-end recovery of 9.3 ms, strictly comply with the IEC 61131-3 real-time standard of 10 ms.

Compared to traditional multi-chip heterogeneous redundancy solutions, the integrated intrinsic security controller chip offers superior performance in terms of physical footprint, power consumption, design complexity, and, most importantly, arbitration speed, making it a practical and deployable solution for next-generation industrial controllers.

The MimicPLC architecture, employing the AHB-Lite bus and the integrated security controller, is therefore particularly suited for industrial control domains with stringent real-time and reliability requirements but moderate data bandwidth needs, such as process automation, power grid control, and railway signaling systems.

7.1. Limitations

Despite the promising results, this study has several limitations that warrant acknowledgment.

Attack assumption scope: The current detection mechanism assumes that attacks manifest as divergent AHB bus transactions. Covert attacks that produce identical malicious behavior across all three cores (e.g., via a common firmware vulnerability or bus protocol exploit) may evade detection. Proactive countermeasures such as periodic random CPU reset are employed but are not guaranteed to catch all such scenarios.

Single point of failure: The policy CPU (RISC-V), while protected by hardware isolation and firmware integrity checks, remains a single point of failure at the system level. Safeguards including hardware-based arbitration logic and bypass mode are in place (see Section 2.4), but a hardware attack on this core could compromise the arbitration logic.

Platform specificity: The current prototype is implemented on the ESC0830 chip and validated using an FPGA-based testbed. The portability of the proposed mechanism to other heterogeneous platforms or commercial off-the-shelf MCUs requires further validation.

Simulation environment: Experimental results, including latency measurements, are obtained from RTL simulations rather than from fully fabricated silicon. Real-world deployment may introduce additional variables (e.g., temperature effects, electromagnetic interference) that could affect performance.

Lack of formal verification: The arbitration logic, finite-state machine, and recovery protocol have been validated through simulation but lack formal mathematical verification, which is an important requirement for safety-critical PLC environments.

7.2. Generalization Potential

The core principles of MimicPLC—heterogeneous redundancy combined with hardware-level bus arbitration—are not limited to the specific ESC0830 chip or AHB-Lite bus protocol. The architecture can be generalized to other bus protocols (e.g., AXI4, APB, Wishbone) with corresponding modifications to the Checker module’s interface logic. Beyond industrial PLCs, the proposed architecture is applicable to other cyber-physical systems with stringent real-time and security requirements, including automotive electronic control units (ECUs), avionics systems, and medical device controllers. While our prototype uses a custom ASIC, the scheduling IP can be synthesized as a soft-core on commercial FPGA platforms (e.g., Xilinx Zynq, Intel Cyclone V SoC), enabling broader adoption without requiring custom chip fabrication.

7.3. Future Work

Future work will focus on three directions to advance this paradigm:

Scalability and Policy Optimization: Exploring architectures with a greater number and variety of heterogeneous cores and developing intelligent, adaptive scheduling policies that can dynamically adjust redundancy modes and resource allocation based on real-time threat levels and system load.

Enhanced Intelligent Detection: Integrating lightweight machine learning algorithms within the policy CPU to analyze long-term behavioral patterns, aiming to detect more sophisticated, slow-burning APT-style attacks that may evade simple rule-based consistency checks.

Formal Verification and Certification: We plan to apply formal verification methods, including model checking and SMT-based analysis, to rigorously verify the correctness and security properties of the scheduling state machine and arbitration logic. Specifically, we aim to formally prove properties such as: (1) the system never outputs a malicious transaction; (2) recovery always completes within the bounded time; and (3) the system never enters a deadlock state. Simultaneously, pursuing relevant functional safety (e.g., IEC 61508 SIL 3) and industrial cybersecurity (e.g., IEC 62443) certifications is crucial for fostering industry trust and adoption.

In summary, MimicPLC represents a significant leap forward in building inherently secure, resilient, and high-performance industrial control systems. By embedding security as a fundamental hardware property with rapid nanosecond-scale arbitration for detection and millisecond-scale end-to-end recovery, this work provides a concrete pathway to defend critical infrastructure against both known and emerging cyber-physical threats.