High-Speed PLC Processors with Advanced Computing Capability for Industrial Automation

High-speed PLC processors have quietly moved from “nice to have” to “critical infrastructure” in modern plants. They sit at the center of smart factories, edge analytics, and high-speed motion, while still being expected to deliver rock-solid determinism and safety. When you upgrade from a legacy PLC CPU to a modern, compute‑rich platform, you are no longer just swapping a controller; you are reshaping how your operation uses data, manages risk, and justifies capital spend.

As a systems integrator, the hardest projects I see are not the brand‑new greenfield lines. The really tough ones are the plants trying to bolt analytics, traceability, and IIoT onto PLC platforms that were selected years ago for basic sequencing. The recurring theme is always the same: the CPU, memory, and communications showed up as “checkboxes” on a spec sheet, not as deliberate design decisions. The result is slow scan times, saturated processors, and networks that cannot keep up.

High-speed PLC processors and advanced computing platforms exist to solve exactly that problem. The goal is not raw clock speed; it is controlled, deterministic performance with enough headroom for data, networking, and security. This article unpacks what that means in practical terms, where the real benefits show up, and how to specify and deploy these capabilities without overpaying or overcomplicating your plant.

From Relay Replacement to Industrial Computer

Programmable logic controllers started life in the late 1960s as a replacement for hard‑wired relay logic in automotive plants. Sources like Empowered Automation and Rockwell Automation describe PLCs as rugged industrial computers that read inputs, execute user‑defined logic, and drive outputs in real time. Eaton characterizes them as solid‑state devices that act as the “brains” of a machine or process.

Early PLCs did one job well: deterministic, repeatable control of discrete logic. They were designed to survive electrical noise, vibration, and wide temperature ranges while running fixed programs that rarely changed. Over time, PLCs gained analog I/O, better programming tools, and modular expansion, but they were still fundamentally controllers, not general-purpose computers.

Modern industrial automation has raised the bar. CTI Electric’s discussion of smart factories emphasizes interconnectivity, adaptability, and transparency. A smart factory is described as an environment where machines, sensors, and controllers communicate in real time, where data is continuously collected and analyzed, and where systems adjust dynamically to changes in demand, supply chain delays, or equipment wear. In that model, the PLC is no longer just a sequencer; it is a central node in a data‑driven architecture.

Vendors and practitioners have responded by pushing PLC CPUs into territory that looks much closer to embedded industrial computers: multicore processors, Linux or real‑time operating systems, megabytes of program and data memory, built‑in security, and support for AI and advanced analytics at the edge. Arrow’s overview of PLC platforms based on STMicroelectronics STM32MP1 and STM32MP2 families is a good example of where things are headed.

What “High-Speed, Advanced Computing” Actually Means in a PLC

Marketing language around “high-speed” and “advanced” is often vague. In practical engineering terms, those phrases refer to a specific set of capabilities: CPU performance, memory architecture, real-time networking, supported languages and libraries, and integrated security.

Processor architecture and raw performance

Maple Systems points out that CPU speed in megahertz or gigahertz and the underlying architecture (for example, 32‑bit versus 64‑bit) determine how well a PLC handles complex logic and high-speed processes. That is not an academic distinction. If you are coordinating multi‑axis motion, executing advanced PID loops, and logging data every scan, the CPU either has the headroom or it does not.

Arrow describes a reference PLC platform based on the STM32MP135, a 32‑bit Arm Cortex‑A7 running at 1 GHz. For PLC workloads it provides about 16 MB of program memory and 32 MB of data memory, plus non‑volatile storage. Instruction execution is on the order of 4 nanoseconds per basic PLC instruction, high‑speed I/O interrupts respond in less than 1 microsecond, and higher‑priority interrupt tasks respond in under 10 microseconds. With EtherCAT as the fieldbus, the same platform can achieve distributed clock cycle times around 250 microseconds for small slave counts and roughly 1 millisecond even with a few dozen devices, while coordinating up to 32 motion axes.

Those are not numbers you need to memorize; they are a concrete illustration of what modern PLC CPUs can do. The combination of gigahertz‑class cores and carefully designed real‑time firmware enables deterministic performance at cycle times that would have been reserved for specialized motion controllers a generation ago.

At the next step up, Arrow highlights STM32MP257‑based platforms that use dual 64‑bit Arm Cortex‑A35 cores at 1.5 GHz plus an Arm Cortex‑M33 microcontroller at 400 MHz. That split architecture is designed so one side can run a Linux environment and high‑level applications while the microcontroller side handles hard real‑time tasks.

Memory architecture: program, data, and storage

Maple Systems and AutomationDirect both stress that PLC memory is not a single number. Program memory holds the logic; data memory holds process variables, recipes, and historical values. AutomationDirect offers a simple sizing guideline of about 5 words of program memory per discrete device and 25 words per analog device, with the caveat that complex non‑sequential logic may need more.

When you move into high-speed, computing‑rich PLC platforms, megabytes of memory become the norm. The STM32MP135 example with 16 MB of program and 32 MB of data memory is typical at that level. That capacity allows more than just a larger ladder program. It enables extensive data logging, recipe management, diagnostics buffers, and even file‑based operations alongside the control logic.

In practice, this matters when you start integrating edge analytics or sophisticated diagnostics. Schneider Electric’s modernization guidance notes that modern PLCs and process automation controllers can convert raw process data such as vibration, temperature, pressure, and flow into profitability metrics like cost per ton or energy per unit of product. That kind of real‑time accounting requires both compute and memory on the controller side, even if some analytics ultimately live in the cloud.

Real-time industrial networking

Texas Instruments frames modern PLC, DCS, and PAC design squarely around real-time industrial communication. Their PRU‑ICSS industrial communication subsystem is designed to support a wide range of fieldbuses and Ethernet‑based protocols, including Time‑Sensitive Network capabilities for deterministic, time‑synchronized traffic over gigabit Ethernet.

The network stack around the CPU matters as much as the CPU itself. Arrow’s STM32MP1/MP2 solutions emphasize dual or triple Ethernet ports, multiple CAN‑FD interfaces, and support for protocols such as EtherCAT, Modbus, and MQTT. IO‑Link and Single‑Pair Ethernet extend communication down to smart sensors and actuators, while traditional 4–20 mA loops and HART remain in the picture for legacy instrumentation, as Texas Instruments notes.

The takeaway is simple. In a high‑speed PLC platform, the processor is not just crunching ladder logic; it is continuously managing multiple real‑time network stacks. That is why CPU load management becomes critical.

Software stack, languages, and libraries

A fast CPU without the right software stack is largely wasted. The Arrow reference designs for STM32MP135 describe runtime environments that support all five IEC 61131‑3 languages: Ladder Diagram, Function Block Diagram, Structured Text, Sequential Function Charts, and Instruction List. Beyond the languages, the same runtime includes standard function block libraries, high‑performance PID, PLCopen motion control, communication function blocks for bus protocols, MQTT clients, JSON handling, free‑protocol TCP, UDP, and CAN, and integrated file system support.

On the more application‑engineering side, Maple Systems emphasizes software features such as online editing (changing logic while the PLC runs), simulation modes that let you test logic without hardware, automatic device detection, and rich diagnostics and documentation tools. Their modular PLC line is marketed with the promise of familiar programming languages, pre‑made projects, online edit mode, and built‑in error detection.

The reason advanced CPUs matter here is that each of these runtime capabilities consumes resources. Simulation, advanced diagnostics, and communication stacks all add overhead. Without sufficient compute headroom, you will quickly run into the limits that Premier Automation warns about when they discuss communication‑heavy applications and CPU load.

Integrated security and safety

As PLCs become more connected and powerful, they also become more exposed. Siemens explicitly cautions that protecting industrial plants from cyber threats requires a holistic industrial security concept that goes beyond any single vendor’s products. STMicroelectronics positions its STM32MP2 family as targeting advanced security certifications, with support for trusted execution, confidential computing, and secure lifecycle management.

From a CPU selection standpoint, that means modern PLC processors increasingly include hardware acceleration for cryptography, secure boot mechanisms, and support for secure partitioning. These features allow encrypted communications and hardened runtime environments without sacrificing control loop performance.

Why CPU Speed and Compute Headroom Matter on the Plant Floor

High-speed PLC processors enable capabilities that older controllers simply cannot deliver in a reliable way. In real projects, the gains tend to fall into three categories: deterministic control at short cycle times, communication‑heavy architectures, and data‑centric operations.

Deterministic control and short scan times

Maple Systems describes PLC scan time as the duration of one cycle of reading inputs, executing the control program, and writing outputs. These cycles are usually in milliseconds, and shorter scan times give more responsive control, which matters for high‑speed manufacturing and precise motion.

The STM32MP135 PLC reference from Arrow takes this further with interrupt‑driven architectures and EtherCAT cycle times in the hundreds of microseconds. When combined with high‑performance motion function blocks and up to 32 axes of control, that kind of CPU enables packaging and assembly applications where a few milliseconds of delay translate directly into missed registration marks, inconsistent seal quality, or unstable motion.

Real-world case studies from Industrial Automation Co. highlight similar trends even when they do not focus explicitly on CPU specs. A global automotive manufacturer that adopted Siemens S7‑1500 PLCs saw production downtime reduced by about 30 percent. A packaging company that implemented Mitsubishi’s FX5U PLC achieved a 20 percent increase in output within six months. In both cases, the PLCs brought faster processing and better program organization, which allowed tighter control and more responsive error handling.

Communication‑heavy architectures

Premier Automation calls out CPU load as a critical factor in communication‑intensive applications and recommends keeping peak cyclic load around 65 percent and static load roughly 60 percent to maintain throughput and response times. They specifically note that heavy use of communications and OPC servers demands higher processing power.

That observation lines up with field deployments discussed on the Inductive Automation community forum, where an engineer described an Oil and Gas architecture using Ignition SCADA and MQTT across roughly 400 Allen‑Bradley Micro800 series PLCs and Maple Systems HMIs on a private cellular network, processing on the order of 700,000 tags daily. In a system like that, it is not unusual for processors to spend a significant portion of their time on protocol handling, security, and data marshaling rather than purely on local I/O logic.

High‑speed processors with dedicated communication subsystems and deterministic Ethernet support, as described by Texas Instruments and Arrow, are designed precisely for this environment. They allow the control logic to remain deterministic even while the controller participates in multiple time‑critical networks and streams data to SCADA, historians, and cloud platforms.

Data, analytics, and profitability tracking

Schneider Electric frames PLC modernization as an economic decision rather than a maintenance exercise. In their modernization guidance, they emphasize using modern PLCs and Ethernet‑enabled process controllers to support real-time analytics and accounting. By combining process data such as vibration, temperature, pressure, and flow with energy and material consumption, operators can monitor metrics like cost per ton of product or energy per unit of treated water.

They describe using a profitability index derived from these streams to justify modernization, and they point out that cloud‑based historians now make it feasible to store and analyze large volumes of data over long periods. In a forest products example, modernizing 45 PLCs, upgrading networks, and adding redundancy and online change capability resolved outages that had been costing tens of thousands of dollars per hour, with a reported payback around one and a half years.

Seifert Engineering makes a similar strategic point. They argue that PLCs are evolving from simple controllers into gateways for digital transformation, linking shop‑floor operations with cloud dashboards, mobile alerts, and enterprise planning systems. Many plants already collect rich operational data but do not fully use it for predictive maintenance or real‑time decision support.

None of these use cases are realistic on underpowered CPUs with tiny data memory and basic serial links. High-speed, computing‑capable PLC platforms are what make it practical to perform preprocessing, buffering, and smart alarming at the edge while still meeting real‑time control deadlines.

Core Design Elements of a High-Speed PLC Platform

When you strip away the marketing labels, advanced PLC processors share a common set of design elements. Understanding these makes it much easier to specify and evaluate platforms.

This comparison uses concrete values taken from Arrow, Maple Systems, Texas Instruments, and other sources to illustrate direction, not to promote specific silicon. The key point is that modern PLC processors are part of an integrated platform that includes deterministic networking and secure, flexible software, not just a faster chip.

AutomationDirect’s worksheet on choosing a PLC reinforces that the process still begins with fundamentals. You classify the installation as new or an upgrade, document environmental conditions, estimate I/O quantities and types, document specialty functions like motion and high‑speed counting, and then size CPU memory and scan performance. High-speed CPUs do not change that workflow; they simply expand what is possible once those basics are understood.

Pros and Cons of High-Speed, Computing-Rich PLC CPUs

There is a tendency to treat “faster and more powerful” as inherently better. In plant automation, that is not always true. High-speed, advanced PLC processors bring real benefits, but they also introduce trade‑offs.

On the positive side, the performance and flexibility gains are tangible. Industrial Automation Co. documents several examples where modern PLC platforms delivered double‑digit improvements. Siemens S7‑1500 systems helped a car manufacturer cut downtime by around 30 percent. In food and beverage, a move to Allen‑Bradley CompactLogix controllers increased efficiency by about 25 percent and reduced energy usage by 15 percent. Mitsubishi’s FX5U in a packaging application increased output by 20 percent, while Schneider’s Modicon M580 boosted wind energy output by 12 percent and reduced downtime through predictive maintenance. ABB’s AC500 series enabled a mining operation to cut equipment failures by 40 percent, and Omron controllers helped an electronics manufacturer reduce defect rates by 18 percent.

Not all of those gains are purely due to CPU speed, of course. Better diagnostics, richer programming environments, and modern networks all contribute. However, without enough compute headroom, it becomes difficult to implement the advanced control strategies, motion profiles, and analytics that underpin those improvements.

High-speed CPUs also support future‑proofing. RL Consulting emphasizes choosing PLC platforms that can accommodate evolving technologies such as IIoT integration and AI‑driven analytics. Arrow’s STM32MP2‑based PLC designs explicitly add multimedia and AI features with a neural processing unit and graphics acceleration, while Texas Instruments positions their multicore processors and PRU‑ICSS as a bridge across the evolution from classic 4–20 mA loops to deterministic gigabit Ethernet.

On the downside, there is cost and complexity. Industrial Automation Co. notes that high‑end platforms like Allen‑Bradley ControlLogix can easily exceed several thousand dollars for the CPU alone, before software licensing and training. Siemens S7‑1500 systems start in the midrange and scale up. Engineers on the Inductive Automation forum caution that these platforms are not beginner‑friendly from a cost perspective, even though they are widely used in industries such as Oil and Gas.

Advanced CPUs also mean more surface area to secure and maintain. Siemens is explicit that their products are only one part of a comprehensive security strategy. With Linux‑capable processors and Ethernet everywhere, you must treat PLCs as part of your cybersecurity posture, not as isolated boxes on an island network. That introduces new responsibilities for patching, access control, and threat monitoring.

Finally, it is easy to overspec. Premier Automation warns that over‑specifying controllers adds unnecessary cost, while under‑specifying forces redesign. A simple fixed‑function machine running basic I/O and a few timers does not benefit meaningfully from a multicore, AI‑enabled PLC CPU. The extra capability can even encourage unnecessary complexity in the control logic.

How to Specify a High-Speed PLC Processor for a Real Project

In practice, selecting a high-speed PLC processor should follow a disciplined, requirements‑driven process. The difference from a conventional PLC spec is that you must explicitly consider data, networking, and future workloads alongside classic control requirements.

Start with the process and system requirements. RL Consulting recommends defining the scale of automation, the number of machines or processes to control, and the complexity of those processes, ranging from simple on/off tasks to advanced motion, data handling, and safety. Document environmental factors such as temperature range, dust, moisture, and vibration. AutomationDirect notes that typical industrial controllers operate in roughly 32–130 °F environments, and more extreme conditions may require rugged designs or protective enclosures.

Next, define I/O and specialty functions. Estimates of digital and analog I/O counts, as well as high‑speed counters, pulse‑width modulation outputs, and safety I/O, drive both the base controller choice and the need for expansion modules, as highlighted by Maple Systems and AutomationDirect. If you know that motion control, multi‑axis coordination, or precise timing is involved, that points towards platforms with strong real‑time performance like the EtherCAT‑capable designs described by Arrow.

Once you understand the process and I/O, size memory and CPU. Use AutomationDirect’s rule of thumb for program memory as a starting point, then consider data needs: trending, recipes, setpoint archives, and local buffering for historian connections. For CPU, think in terms of scan time and load, not just clock frequency. Premier Automation’s guidance to keep cyclic CPU load below about two‑thirds of capacity is practical; it leaves room for communications, online edits, and future feature additions. If your architecture relies heavily on Ethernet, OPC servers, or MQTT, follow their advice and treat communications as a first‑class CPU load driver rather than an afterthought.

Communication and networking requirements deserve special attention for advanced PLC processors. RL Consulting suggests ensuring compatibility with required protocols such as Ethernet/IP, Modbus, and Profibus and verifying that the PLC can integrate cleanly with SCADA, HMIs, and remote I/O. Texas Instruments recommends using multicore processors with dedicated industrial communication subsystems so you can support both legacy interfaces and modern Ethernet with deterministic performance. Arrow’s STM32MP1/MP2 platforms underline the value of having EtherCAT, multiple Ethernet ports, CAN‑FD, and MQTT all available on the same hardware.

Software, tools, and programming languages are another decisive factor. Maple Systems emphasizes that intuitive software, strong diagnostics, online editing, simulation, and good documentation significantly reduce development and maintenance effort. Empowered Automation points out that different IEC languages are better suited to different tasks, with ladder logic being ideal for discrete control, structured text for complex algorithms, and function block diagrams for reusable process logic. When you select a high‑speed CPU, verify that the engineering tools and runtime actually let you exploit that performance instead of fighting it.

Finally, revisit lifecycle, support, and ecosystem. RL Consulting advises favoring reputable brands that offer long‑term product availability and robust support. Seifert Engineering recommends asking whether your PLC infrastructure is truly future‑ready and whether it will interoperate with robotics, sensors, and enterprise systems. If your plant operates across multiple sites or countries, consider whether standardizing on one or two high‑performance PLC platforms, as Premier Automation suggests with a single control platform strategy, will reduce training, spare parts, and integration overhead.

Modernization and ROI: Making the Business Case

Even when the technical case for high-speed PLC processors is clear, capital approval often hinges on return on investment. Modernization guidance from Schneider Electric and upgrade arguments from PLC‑focused publications converge on a few themes that resonate with finance teams.

Firstly, modernization reduces unplanned downtime and safety risk. Schneider Electric notes that aging PLC systems increase the risk of unplanned shutdowns, higher maintenance costs, and safety incidents, all of which erode profitability. In their forest industry example, modernizing 45 PLCs along with the supporting network and implementing services eliminated frequent outages that had been costing tens of thousands of dollars per hour. The project improved redundancy, allowed online program changes, integrated cleanly with an existing DCS, and delivered a reported payback of about one and a half years.

Secondly, performance and efficiency gains are measurable. Industrial Automation Co. presents multiple case studies where modern PLCs enabled double‑digit improvements in throughput, energy efficiency, or defect rates. PLClGurus argues that upgrading PLCs should be treated as a strategic investment, noting cases where faster processors and modern platforms drove about 25 percent reductions in cycle time and roughly 10 percent to 30 percent reductions in downtime through better diagnostics and data visibility.

Thirdly, modern processors unlock data and analytics capabilities that support continuous improvement. Schneider Electric’s profitability index concept, Seifert Engineering’s focus on turning PLCs into data gateways, and CTI Electric’s smart factory characteristics all emphasize using PLC data for real‑time decision making. That can mean optimizing energy use, fine‑tuning batches, or scheduling predictive maintenance based on trends in vibration or runtime rather than fixed intervals.

The strongest justification usually combines these elements. You document current downtime, quality losses, and energy waste; you translate expected performance improvements into dollars using case studies from sources such as Schneider Electric or Industrial Automation Co.; and you highlight secondary benefits such as better data for OEE, improved safety through integrated safety functions, and readiness for future digital initiatives.

Implementation Patterns That Reduce Risk

Deploying high-speed PLC processors is not just a hardware change. It is an architectural shift, and the way you implement it often determines success more than the spec sheet.

Premier Automation recommends delaying final controller selection until the process concept is mature and then bench‑testing controllers before committing. In practice, that means prototyping critical logic and communication paths on a test rack, measuring scan times and CPU load with realistic message volumes, and verifying that online edits and diagnostics work as expected.

Maple Systems and Empowered Automation recommend strong documentation for PLC programs. With advanced CPUs and richer features, codebases tend to grow. Thorough documentation of function blocks, variables, and semantics is essential to keep the system maintainable, especially when future engineers may not have been involved in the original design.

Standardizing on a single or limited set of control platforms is another pragmatic pattern. Premier Automation points out that using one control platform across robotics, motion, and general automation can reduce maintenance effort and spare parts inventories. It also makes it easier to build internal expertise on specific high‑speed CPUs and toolchains.

On the networking side, Texas Instruments and Arrow suggest leveraging integrated communication subsystems and TSN‑capable Ethernet to manage growing bandwidth and latency demands. RT Engineering recommends mapping existing equipment and I/O, planning structured data exchange with SCADA, MES, ERP, and HMIs, and executing thorough simulations and live tests before full production cut‑over. For distributed systems like the Oil and Gas deployment described on the Inductive Automation forum, where a private cellular network carries hundreds of thousands of tags, careful design of communication patterns and exception handling is vital.

Security should be treated as a first‑class design constraint. Siemens advises that a state‑of‑the‑art industrial security concept must be maintained continuously and that vendor products form only one part of such a strategy. High-speed, networked PLCs with Linux and open protocols should be deployed with role‑based access control, segmented networks, and clear patching procedures, not left exposed on flat networks.

Finally, plan for growth and change. Maple Systems warns against choosing the cheapest controller for tasks that are likely to evolve, because that approach becomes more expensive over time. RL Consulting and Empowered Automation recommend selecting platforms that support future technologies such as IIoT and AI‑assisted analytics. Arrow’s STM32MP2‑based controllers, with their neural processing units and multimedia capabilities, and Texas Instruments’ gigabit‑capable, protocol‑flexible processors are examples of that direction.

Brief FAQ

Q: How do I know if my process really needs a high-speed PLC processor instead of a simpler controller? A: Look at your control and data profile, not just the machine type. If you have high‑speed motion, tight tolerances, or very short cycle times, if your architecture relies on Ethernet‑based fieldbuses such as EtherCAT or Profinet, if you plan extensive data logging or integration with IIoT platforms, or if you must coordinate many axes or devices in real time, then the CPU, memory, and networking features of a high‑performance PLC platform are directly relevant. If your application is simple discrete control with modest I/O and little networking, a simpler controller can often deliver the same outcome at lower cost.

Q: Will dropping a faster CPU into an old PLC rack automatically deliver better performance? A: Not reliably. Schneider Electric’s modernization work shows that real gains typically come from coordinated upgrades to PLCs, networks, and integration layers, not from CPU replacement alone. Bottlenecks often sit in networks, I/O architectures, or program design. Before investing in a faster processor, benchmark your current system’s scan times, CPU load, communication delays, and program structure. Then plan modernization that addresses the true constraints.

Q: How much CPU load is too much for a communication‑heavy PLC application? A: Premier Automation recommends keeping peak cyclic CPU load around two‑thirds of capacity and static load somewhat lower. That guidance is practical for high‑speed, communications‑rich controllers as well. Operating continually near maximum load leaves no room for bursts in messaging, online edits, or future feature additions and tends to degrade response times, especially for OPC and similar services. If staying in that safe band requires a more powerful CPU, that is often a justified upgrade.

In high‑speed industrial automation, the PLC processor has become more than a logic engine; it is the industrial computer at the center of your operations. Choosing and applying that processor thoughtfully—grounded in real process needs, communication demands, and future digital ambitions—is what separates a fragile “smart” factory from a robust, profitable one. As a project partner, my advice is simple: treat CPU performance, memory, and networking as strategic design decisions, not line‑item checkboxes, and you will get the return you expect from modern automation.

References

1. https://www.houstonelectricinc.net/our-blog/how-plc-programming-services-enhance-efficiency-in-manufacturing-automation
2. https://www.plcgurus.net/10-reasons-your-manufacturing-process-needs-a-plc-upgrade/
3. https://www.empoweredautomation.com/best-practices-for-implementing-automation-plc-solutions
4. https://www.seifert.com/the-future-of-control-why-plcs-are-critical-to-smarter-faster-manufacturing
5. https://support.automationdirect.com/docs/worksheet_guidelines.html
6. https://ctielectric.com/how-smart-factories-use-plcs-to-boost-efficiency/
7. https://maplesystems.com/10-things-to-consider-when-choosing-new-plc/?srsltid=AfmBOoooiGl0Mq-h4HabEvi-KWiBQTxznX260a49oHzoQNx-HU1TemAs
8. https://info.premierautomation.com/blog/8-practices-for-specifying-plcs-pacs-or-pc-controllers
9. https://processsolutions.com/the-role-of-plcs-in-manufacturing/
10. https://rlconsultinginc.com/how-to-choose-the-right-plc-for-your-industrial-automation-project/