If your project involves data collection, multi-protocol conversion, lightweight AI inference, or future feature expansion, a PLC + ARM architecture (often referred to as a PLC + industrial edge gateway solution) offers more advantages than a pure PLC system. If the project only requires simple logic control without any need for cloud data, a pure PLC solution is sufficient.
Engineers who have worked extensively on industrial sites often share the same experience: traditional PLCs are stable enough, but they are increasingly “stretched thin” when it comes to today’s data demands. For example, on an automotive parts production line, the manager might want to monitor the line status, calculate hourly yield, predict equipment failures, and even upload data to the cloud for global analysis. Achieving all this makes the program increasingly complex, and the debugging cycle significantly longer. While a traditional PLC can ensure precise cylinder movements, its ability to handle complex algorithms and connect directly to the cloud is often limited.
This is where the PLC + ARM architecture comes into play—letting the PLC focus on control while the ARM handles data and intelligence. The ARM side provides computing power, rich communication interfaces, and a Linux ecosystem, capable of handling tasks that traditional PLCs are less suited for. However, not every project is suitable for this “combo approach.” The following five conditions can help you determine whether your project should adopt it.
Why More and More Projects Are Considering a PLC + ARM Architecture
Traditional PLCs operate in a cyclic scan mode and excel at logic control and hard real-time response. However, when it comes to complex computations, multi-protocol conversion, or cloud data integration, although these tasks can be handled via expansion modules or third-party gateways, they often come with high development costs, complex configuration, and limited flexibility.
In contrast, industrial computers based on the ARM architecture (often called “edge intelligent gateways” or “ARM controllers”) generally outperform mid-to-low-end PLC CPUs in floating-point calculations and data processing. They also offer a more open software ecosystem and richer connectivity options. Combining the two allows for the creation of a layered data processing and interconnection structure alongside the control layer, leveraging the strengths of each.
From experience, this type of solution is more of a compromise than a universal fix—it can add data processing capabilities to a production line without altering the original PLC control logic, but the team needs to have some basic knowledge of Linux and network configuration.
Condition 1: Does the system require data processing or algorithmic decision-making?
If a project only requires simple logic control (for example, “press a button, motor starts”), a PLC alone is sufficient. However, once the project involves the following needs, a PLC + ARM architecture becomes worth considering:
-
Lightweight AI inference: For example, using a camera to identify product colors, check for labels, or count parts. Some ARM processors integrate NPUs (e.g., 1 TOPS) capable of running lightweight models, suitable for low-resolution images, simple classification, or single-object detection in basic scenarios. While they cannot replace complex multi-object vision systems, they can handle some auxiliary decisions at the edge.
-
Complex rule-based strategies: For instance, determining whether to trigger a warning based on multiple factors such as equipment vibration frequency, temperature trends, and historical data. Implementing such logic on ARM using Python or Node-RED is generally more efficient than writing ladder logic or structured text on a PLC.
-
Statistical analysis: Real-time calculation of device OEE, energy consumption trends over the past hour, and report generation are tasks better suited for ARM.
In many production line retrofit projects, removing statistical tasks from the PLC has shortened PLC programs by over 30%, significantly improving debugging efficiency. The ARM side is suitable for non-real-time, computation-intensive data tasks, but is not suitable for control loops requiring hard real-time response. If data processing results need to be used for closed-loop control, communication latency must be evaluated, and the PLC should retain final decision authority.
Condition 2: Does the system require multi-protocol conversion or direct cloud integration?
This is one of the areas where ARM architecture truly excels. While many traditional PLCs have communication capabilities, directly connecting to public clouds or handling diverse protocols can be relatively complex. In the following scenarios, an ARM controller acts as a “translator” and “relay”:
-
Equipment from different brands: A workshop may have Siemens PLCs, Mitsubishi inverters, and Modbus meters. An ARM controller can interface with all of them simultaneously, converting their data into a unified protocol such as OPC UA or MQTT for seamless data integration.
-
Data needs to be pushed to mobile devices: For example, sending critical alarms or production data to apps like DingTalk or WeCom.
-
Data needs to be uploaded to the cloud for long-term storage and analysis: Ensuring stable transmission of data to cloud databases via 4G, 5G, or wired networks.
Some ARM industrial computers on the market support multiple mainstream industrial protocols either through pre-installed industrial gateway software or custom driver development, including Modbus, OPC UA, EtherNet/IP, and certain PLC proprietary protocols. Different vendors vary significantly in protocol coverage, concurrent point capacity, and software maturity, so these factors must be carefully considered during selection.
For example, the EC300 series ARM industrial computers come pre-installed with Node-RED and NeuronEX-Lite, enabling multi-protocol collection and unified conversion via software. Their Linux-based open environment also supports secondary development and feature expansion. This design decouples protocol conversion from hardware, making the system more flexible for future adjustments and upgrades.
In practical applications, the number of concurrent points and processing performance still need to be evaluated based on project requirements (such as point scale and refresh cycle) and hardware resource configuration.
Condition 3: Does control involve safety and real-time requirements?
This is a “Red Line” that must not be crossed when choosing a PLC + ARM architecture: any actions that involve personal safety or risk of equipment damage must be controlled directly by the PLC.
The ARM side typically runs a Linux system, which does not provide the same level of real-time performance as a hard PLC, and may be subject to system crashes or network interruptions. Therefore, a reasonable division of labor is: ARM as the “brain” and PLC as the “muscle,” working closely together. The ARM, as the brain, primarily handles data processing, logical decision-making, and human–machine interaction, then sends instructions to the PLC via industrial Ethernet or serial port (e.g., “temperature too high, prepare to stop”). The PLC, as the muscle, is responsible for emergency stop, safety light curtains, and other hard real-time actions. PLC programs must run independently and not be affected by the state of the ARM.
Additionally, the system design must account for ARM failure—this is critical. If the ARM crashes or the network fails, the PLC should automatically switch to a safe state or a degraded operation mode according to a preset watchdog mechanism or communication timeout logic, ensuring the production line does not go out of control. The ARM controller itself should also have a hardware watchdog to automatically reboot in case of abnormality. Moreover, communication between the PLC and the ARM should support reconnection and data buffering to prevent data loss.
In practice, this is often the most underestimated risk in retrofitting older production lines. It may sound ideal, but in reality, network latency and maintenance costs must be considered. Data exchange between PLC and ARM (typically via Ethernet or serial port) can have millisecond-level or higher delays, depending on network load and protocol type. For fast-response coordinated control, it is essential to evaluate whether the latency is within acceptable limits and implement proper data synchronization mechanisms.
Some ARM controllers provide isolated DI/DO interfaces. These are generally used for non-safety-critical signal interactions (e.g., status indicator lights, auxiliary feedback signals) and are not recommended for driving actuators that could pose safety risks. All critical controls should always be handled by the PLC.
Condition 4: Does the project require future expansion?
Many automation projects share a common pattern: the first phase only addresses basic requirements, but in the second or third phases, new functionalities are continually added. While traditional PLCs can easily expand I/O modules, adding an AI analysis feature, switching cloud platforms, or connecting new smart devices is often limited by the main CPU’s performance or communication interfaces.
The layered PLC + ARM architecture offers clear advantages in scalability:
-
Horizontal expansion of interfaces: With the ARM side’s rich interfaces (USB, HDMI, CAN, etc.), cameras, large displays, barcode scanners, and other smart devices can be added later.
-
Vertical expansion of applications: The ARM’s Linux system allows installation of new software containers or applications in the future—for example, adding a Web SCADA visualization interface or adjusting the data processing flow—without modifying the underlying PLC program.
However, expansion is not unlimited. CPU headroom, storage space, and network bandwidth on the ARM controller must be considered. For example, if the first phase already pushes CPU usage above 70%, adding image processing tasks may lead to performance degradation. When selecting a system, plan for a 3–5 year horizon and reserve sufficient resources for future growth.
Condition 5: What about operation, maintenance, and debugging complexity?
This is often the top concern for team leaders and on-site engineers: will a new architecture increase debugging and maintenance difficulty?
If designed properly, the ARM side’s software tools can actually reduce overall complexity.
First, it simplifies the PLC program. Complex algorithms, protocol conversion, and data logging tasks are offloaded to the ARM. The PLC only handles logic control, making programs shorter, more stable, and easier to troubleshoot.
Second, ARM controllers usually support remote SSH or web-based configuration. Engineers no longer need to visit the site just to change a parameter.
Finally, the ARM side can run visual programming tools like Node-RED. Data flows can be built quickly through drag-and-drop, lowering the Linux development barrier.
In short, the ARM acts as a “translator,” converting the language of different devices into something the cloud platform can understand. However, this also means that teams using ARM need to have basic Linux knowledge and network configuration skills.
Which projects do not need a PLC + ARM architecture?
To avoid blindly following trends, the following types of projects generally do not require an ARM layer:
-
Pure logic control with no data collection needs: For example, simple relay control or standalone automated machines—PLCs alone are sufficient.
-
Projects with an existing, well-established upper-level system: If the site already has an industrial PC + SCADA system that can meet requirements for the next 3–5 years, there is no need to add an ARM layer.
-
Projects with extremely high safety requirements that cannot tolerate added system complexity: For instance, certain Safety Instrumented Systems (SIS). The simpler the system, the more reliable it is; introducing an additional computing layer could create new risk points.
-
Projects with very tight budgets: Adding an ARM controller increases both hardware and development costs. If the project is highly cost-sensitive, the benefits may not justify the expense.
Typical Deployment Example
In a typical PLC + ARM architecture, the PLC handles real-time I/O control and safety logic, while the ARM edge controller collects production-line data, runs lightweight analytics (such as equipment OEE calculations), and uploads data to the cloud via MQTT or OPC UA. These controllers usually run a Linux system and support building data processing flows through scripts or visual programming. Different products vary in whether they come pre-installed with visual tools and the type of tools provided.
In real projects, different models of ARM industrial controllers differ significantly in the number of interfaces, computing power, and pre-installed software. It is recommended to evaluate and compare options during the selection phase based on the specific application scenario—such as a focus on data collection, lightweight visual assistance, or local HMI—to find the best fit for your system architecture.
Engineering Details to Consider When Selecting
If you decide to adopt a PLC + ARM architecture, in addition to functional requirements, the following engineering details should be considered:
-
Communication latency and synchronization: Data exchange between PLC and ARM can have millisecond-level or higher delays depending on network load and protocol type. For fast-response coordinated control, it is essential to evaluate whether the latency is within acceptable limits and implement proper data synchronization mechanisms.
-
Interface isolation and protection: Industrial environments often have electrical interference. ARM controller interfaces—including serial ports, Ethernet, and I/O—should have electrical isolation and surge protection to prevent a single interface failure from affecting the entire system.
-
Environmental adaptability: If installed in a control cabinet, the ARM controller should operate reliably in a wide temperature range (e.g., -40°C to +70°C). Fanless, passive cooling designs reduce failure points and are more suitable for harsh environments.
-
Software ecosystem and support: Does the vendor provide a complete SDK, example code, and technical support? Are pre-installed tools (e.g., Node-RED, protocol gateways) open-source or easy to extend? These factors directly affect project implementation efficiency.
Summary
PLC + ARM architecture does not aim to replace traditional PLCs, but rather adds a flexible data processing layer to industrial control. When you encounter projects that require data handling, lightweight algorithm execution, multi-protocol integration, cloud connectivity, or future expansion, this combination can provide clear value. However, it is crucial to strictly separate the control layer from the computing layer, ensuring that safety-critical real-time tasks remain fully managed by the PLC, with the ARM serving only as an auxiliary and enhancement layer.
From an engineering perspective, this approach is more like giving your existing PLC system a “data brain” rather than starting from scratch. While the concept looks appealing on paper, its success depends heavily on on-site network conditions and the team’s familiarity with Linux. If you are evaluating this type of architecture, it is recommended to start with a small pilot project to validate communication latency, software compatibility, and team capability before gradually scaling to additional production lines.