PLC: Beyond...

PLCs have long been at the center of factory automation.
In recent years, new technologies such as AI, the cloud and soft PLCs have emerged, and the environment around PLCs is changing significantly. As a PLC engineer, I have collected some thoughts here on what would be interesting to see and how PLCs might evolve.

• How Will Ladder Logic Evolve?
• From Graphical Ladder Diagrams to Text
• AI-Assisted Ladder Program Creation
• Seamless Integration of PLCs and the Cloud
• From Function Blocks to "Classes"
• Using Python Directly from the PLC
• The Future of Soft PLCs and Dedicated Hardware
• Web-Standard Languages for HMIs
• [Summary] From Closed to Open

How Will Ladder Logic Evolve?

I believe ladder logic itself will remain. Ladder makes it easy to understand machine behavior visually, and it is easy for maintenance staff and electrical designers to follow.

In the future, however, we may stop drawing ladder directly and instead use ladder generated from text or by AI.

Designers would write specifications in text, and the PLC would convert them into a ladder view. If that style of development becomes common, I think the gap between software development and PLC development will narrow further.

From Graphical Ladder Diagrams to Text

PLC programming in the AI era and the outlook for open source

1. Background and challenges: the limits of graphical representation

In PLC (Programmable Logic Controller) design, the visually intuitive ladder diagram (LD) has long been the industry standard. However, ladder diagrams built from graphical wiring and blocks fit poorly with the modern software development ecosystem in the following ways.

• Inefficient sharing: data in images or proprietary binary formats is hard to share on social media or the web, or to distribute as code snippets.
• Difficult version control: with conventional ladder diagrams, line-by-line diffs and configuration management with distributed version control systems such as Git do not work well.

To bring AI-based automatic program generation into the FA field, converting ladder diagrams into mnemonics (IL: Instruction List), a text-based representation, and making use of them will be an extremely important key.

2. Approach: IEC 61131-3 compliance and the need for text

2.1 Shifting from manufacturer-specific specifications to the international standard (IEC 61131-3)

Today each PLC manufacturer has its own ladder notation rules, instructions and suffixes, which is a major barrier to AI training and automatic generation. One solution is to base ladder notation (and mnemonic representation) on the international standard IEC 61131-3. If data in a common standard becomes widespread, AI models could accurately learn standard code patterns, dramatically increasing the chance of generating high-quality programs automatically.

2.2 Dividing roles between ladder diagrams and ST

ST (Structured Text) also exists as a textual language and is very effective for complex numeric calculations and data processing. However, for processing that spans multiple PLC scan cycles (communication sequences, motion control, etc.), ladder diagrams, which align easily with timing charts, remain visually and structurally superior. So rather than replacing all control with ST, flexible use that leverages the strengths of both is the realistic approach.

2.3 A realistic workflow

The following process is proposed as a realistic workflow that does not reduce engineer productivity.

1. Development and design: engineers design and debug intuitively in familiar ladder diagrams, as before.
2. Output and publishing: finished ladder diagrams are converted to mnemonics (text) by a tool and published and managed on open platforms such as GitHub.
3. Reuse: others download mnemonics from the web and convert them back into ladder diagrams in their own development environment.

3. Benefits of turning ladder diagrams into text (mnemonics)

Treating ladder diagrams as text data brings the full benefits of modern software development, such as:

• Rigorous source control with Git: change history tracking and branch workflows become easy.
• Easy diffs: changes are easier to identify, improving review efficiency.
• A data source for AI training: as large amounts of high-quality mnemonic code accumulate on the web, AI models (LLMs etc.) can adapt to the FA domain.
• Easy sharing on social media and the web: technical communities become more active and knowledge sharing between engineers accelerates.

4. Conclusion: the future of FA built on accumulated assets

If engineers follow a cycle of "draw in ladder, keep in text," and open source code assets grow on GitHub and elsewhere on the internet, the accuracy of AI generation in the FA industry will improve dramatically.

This would be an important step toward opening up PLC design know-how, which tends to stay with individuals, and building the next generation of automation infrastructure.

AI-Assisted Ladder Program Creation

Design automation and innovation in source code review brought by generative AI

1. Background: generative AI in FA design is becoming real

In recent years, automatic source code generation and automatic bug detection using generative AI (large language models: LLMs) have spread rapidly, mainly in the IT industry. This wave is certainly reaching FA (factory automation), especially the software design of PLCs (Programmable Logic Controllers).

The design and verification of ladder programs, which until now depended on the experience and know-how of skilled engineers, is about to be updated by AI assistance to become faster and safer.

2. Automatic ladder program generation from natural language

The biggest innovation in next-generation AI-assisted development environments is the ability to generate ladder programs (or mnemonics) directly from specifications written in natural language (everyday words).

Engineers simply describe the I/O specifications and operating conditions in text, and the AI interprets the intent accurately and instantly outputs logically sound circuits.

[Example instruction (prompt) to the AI]

In conventional development, engineers worked from such a specification (timing chart), figured out self-holding circuits, timer instructions and interlocks in their heads, and entered them line by line. In future development, AI will assemble the initial code (first draft) in seconds, and engineers will only check and fine-tune it, dramatically reducing man-hours.

3. AI source code review: improving quality and ensuring safety

AI's contribution does not stop at creating programs. AI is also an extremely powerful verification partner for advanced code review (static analysis) of programs written by humans (or generated by AI).

Especially in the FA domain, where safety and reliability are strictly required, AI can automatically detect and point out critical design mistakes and oversights such as:

• Missing interlocks: detects across the whole circuit any collision risk from simultaneous ON or operation conflicts that could cause physical damage.
• Insufficient emergency stop and error handling: checks that outputs are reliably shut off (reset) when an emergency stop signal or servo alarm occurs.
• Timer/counter setting mistakes: points out duplicate addresses and logic errors in timeout settings (unit mistakes or inappropriate delay times).
• Detecting unreachable circuits (dead code): finds "floating circuits" whose conditions can never be met or that are never called, and suggests cleaning up the program.

4. Technical benefits of AI assistance

Building AI into the development process brings substantial benefits such as:

• Dramatic reduction in design man-hours: by leaving routine circuit patterns to AI, engineers can focus on higher-level architecture design and aligning mechanics and software.
• Consistent program quality: high-quality ladder programs that always meet a certain safety standard can be ensured, regardless of an engineer's years of experience
• Shorter debugging periods: AI eliminates potential bugs (missing interlocks etc.) before testing on real equipment (trial runs), drastically reducing on-site trouble and rework

5. Conclusion: the future of FA shaped by engineers and AI working together

A future in which "ladder is generated from natural language and AI reviews its safety" is by no means a distant dream.

As the "Git management via text (mnemonic) ladder" and "compliance with international standards" described above advance and high-quality sample code accumulates on the web, the accuracy of this AI assistance will improve rapidly.

Mastering AI as a tool and focusing on higher-value work such as system optimization and advanced control algorithms will become the new standard expected of FA engineers.

Seamless Integration of PLCs and the Cloud

Next-generation manufacturing IoT accelerated by standard MQTT and REST API support

1. Background: smart factories and growing demand for equipment data collection

In recent years, with the wave of IoT (Internet of Things) and DX in manufacturing, the need to collect and store factory equipment data in the cloud has grown rapidly.

Instead of keeping data on servers inside the factory (on-premises) as before, consolidating data on a scalable cloud platform makes it possible to centrally manage the operating status of multiple factories and perform advanced analysis using machine learning. However, a major barrier has existed between conventional PLCs (Programmable Logic Controllers) and IT systems (the cloud): different protocols.

2. Challenge: the gap between conventional industrial networks and IT protocols

Until now, the data handled by PLCs has been optimized mainly for industrial Ethernet such as EtherNet/IP, PROFINET and CC-Link IE, or for field networks such as Modbus. Although they excel at real-time performance and reliability, they are not suited to communicating with the cloud directly over the internet.

As a result, a relay system such as an industrial PC (IPC), a dedicated IoT gateway or an OPC UA server has traditionally been needed between the PLC and the cloud. This made systems more complex, increased initial investment (hardware and development man-hours), and raised the maintenance burden.

3. Solution: standard support for IT protocols in the PLC

The breakthrough for these challenges is for the PLC itself to support the IT standard protocols MQTT and REST API (HTTP/HTTPS) natively (as standard functions).

This enables an "edge-to-cloud" configuration that eliminates all relay devices and sends data directly from the PLC to the cloud (AWS, Azure, GCP, etc.).

3.1 Integrating MQTT (Message Queuing Telemetry Transport)

MQTT is a lightweight, low-bandwidth publish/subscribe (Pub/Sub) protocol, ideal for periodically sending sensor data and device information covering thousands to tens of thousands of points. If the PLC acts as an MQTT client, rapidly changing time-series data such as equipment "current position," "current value" and "error code" can be streamed to the cloud in real time with minimal network load.

3.2 Integrating REST API (HTTP communication)

With REST API support, the PLC can integrate flexibly with external systems using web-standard formats such as JSON. For example, at "production complete" the PLC could write result data to a cloud database (ERP or MES) via HTTP POST, or conversely fetch the latest "production recipe (parameters)" from the cloud via HTTP GET and apply it to the equipment, making IT-driven batch processing and on-demand two-way communication easy.

4. The innovation and expected benefits of cloud integration

By connecting PLCs directly to the cloud, manufacturing sites will be able to build powerful applications such as the following more easily and quickly.

• Real-time equipment monitoring (dashboards): visualize the operating rate and equipment status of every factory from a PC or smartphone anywhere in the world.
• Data-driven predictive maintenance (PPM): analyze servo motor torque values and cylinder operating times with AI in the cloud, detect signs of part wear or failure in advance, and bring downtime to zero.
• Advanced production analysis and quality control (traceability): instantly link the manufacturing conditions (temperature, pressure, cycle time, etc.) at the time a defect occurred in the cloud, speeding up the cycle of root-cause analysis and process improvement.

5. Conclusion: the future of FA brought by the fusion of OT and IT

When PLCs can speak MQTT and REST API as a "standard language," it means that the previously separate worlds of OT (operational technology) and IT (information technology) truly merge.

Simpler, gateway-less configurations and dramatically reduced development and deployment effort will lower the barrier to IoT adoption for manufacturers of every size and become a powerful foundation that connects shop-floor knowledge directly to corporate management resources.

From Function Blocks to "Classes"

Next-generation control design brought by object orientation in PLCs

1. Background: structuring in current PLC development and its limits

In recent PLC (Programmable Logic Controller) development, with the spread of the international standard IEC 61131-3, modularization with functions (FC) and function blocks (FB), and the use of "libraries" that package them, has become common. This has greatly improved reusability and readability compared with conventional flat ladder diagrams.

However, when implementing advanced and complex control such as motion control and communication control, a new challenge (limit) has emerged: structuring with conventional FBs alone becomes cumbersome to manage.

2. Concrete example: challenges in conventional motion control

In conventional motion control (e.g. PLCopen-compliant FBs), moving a single axis (servo motor) required combining many independent FBs, one for each purpose (function).

• MC_Power (servo ON/OFF)
• MC_Home (homing)
• MC_MoveAbsolute / MC_MoveRelative (positioning)

Each of these FBs must be linked individually to the target "axis (Axis variable data)," and the engineer must manage each instance, its execution condition (Execute flag) and its status separately. As the number of axes grows, programs become huge, increasing the risk of bugs and the effort needed for debugging.

3. Solution: introducing object-oriented "classes" and the expected benefits

The approach that solves these challenges at the root is to bring the concept of "classes (object orientation)," mainstream in modern software development, into the PLC.

3.1 What is a class?

A class is an advanced blueprint (mechanism) for managing related "data (state)" and "processing (behavior)" together. Controlled objects in a PLC (servo motors, communication devices, etc.) can literally be encapsulated (hidden) and handled as a single independent "object."

3.2 Using classes in motion control (in practice)

Once classes can be implemented, you can define a comprehensive "motion control class" that wraps the previously separate FBs internally.
For example, if you create Servo01, an instance of the class, for a particular servo motor, you can write code intuitively and cleanly as follows.

• Properties (data management): axis parameters and current state can be referenced and set directly as attributes of the object, such as Servo01.MaxPosition (maximum position limit) and Servo01.MaxSpeed (maximum speed).
• Methods (executing processing): actions on the axis can be called cleanly in function form, such as Servo01.Move() (start positioning) and Servo01.MoveVelocity() (start velocity control).

3.3 Ripple effects on communication and other fields

The benefits of classes are not limited to motion control. For communication such as socket communication and field networks, encapsulating the sequence of connect, send, receive and disconnect together with the buffer data as a single "communication class" is expected to dramatically improve the reusability of middleware (libraries).

4. Technical benefits of classes

If classes are fully introduced into PLC development and engineers can implement them freely, the benefits will be substantial:

• Better readability through further structuring: program interfaces become simpler, preventing spaghetti code.
• Better quality through encapsulation: internal processing and variables are protected, reducing unintended external data overwrites (conflicts) and improving overall program reliability.
• Fewer man-hours by maximizing component reuse: keeping standardized classes in a library greatly reduces design and verification effort when starting new projects.
• Better maintainability: the scope of changes for bug fixes and feature extensions is confined to the class, making maintenance easier.

5. Conclusion: outlook for future FA development

For engineers who have mastered FUNs, FBs and libraries, learning and implementing the next step, "classes (object orientation)," is a clear roadmap for taking FA development to the next stage.

Some current PLCs are beginning to incorporate elements of object orientation in higher-level languages (ST and some manufacturers' extensions). If class-based design becomes standard in the FA industry, the productivity and quality of industrial software will surely improve dramatically.

Using Python Directly from the PLC

A next-generation control architecture that runs edge AI, image processing and data analysis inline

1. Background: growing demand for advanced data processing at the edge (shop floor)

In recent years, manufacturing sites have been paying more attention to "edge computing," which performs advanced processing in real time right next to the equipment (the edge), rather than just sending data to the cloud. In particular, demand is growing rapidly for running AI-based visual inspection, anomaly detection and advanced statistical analysis inline (within the machine's operating cycle).

However, most of the software assets behind these cutting-edge technologies are developed in Python, while the PLCs that handle shop-floor control run ladder and ST. How to connect these two languages and environments has been a major technical challenge.

2. Challenge: bottlenecks in the conventional "PLC + external PC" configuration

Until now, using advanced Python algorithms (image processing, AI inference, etc.) within PLC control usually meant preparing an "external PC (Windows/Linux)" or "industrial PC (IPC)" separate from the PLC.

• Complex communication programming: data is exchanged between the PLC and the external PC via socket communication, shared memory, databases, etc., so a large amount of communication code (handshake processing, etc.) had to be built on both sides.
• Impact on cycle time: communication overhead (latency) made it difficult to fit AI inference or image analysis into the cycle of very high-speed production lines.
• Hardware cost and installation space: the extra cost of an external PC, the obstacle to saving space in the control panel, and maintenance such as managing PC OS updates were a burden on engineers

3. Solution: calling the Python environment directly from the PLC (inline)

The way past these challenges is a mechanism that lets the PLC's internals (runtime environment) call Python scripts and functions directly and seamlessly.

An environment is expected in which Python's vast set of libraries can be executed like "functions" directly within the PLC's control loop (scan), without any relay communication.

3.1 Inline execution of edge AI inference

AI models trained with frameworks such as TensorFlow or PyTorch (in ONNX format, etc.) are loaded directly into the Python environment inside the PLC. The PLC can pass waveform or pressure data acquired from sensors straight to the Python AI model and feed the "normal/abnormal" inference result back into the control logic within a few milliseconds.

3.2 Advanced image processing with OpenCV

Without expensive dedicated vision sensors, video from a general-purpose camera (USB or GigE) can be brought into the Python environment inside the PLC, and shape recognition, color judgment, alignment calculations and more can be implemented flexibly and cheaply with libraries such as OpenCV.

3.3 Real-time data analysis on site and Web API integration

Using powerful numerical libraries such as NumPy, Pandas and SciPy, statistical processing such as the fast Fourier transform (FFT) of equipment vibration data can be completed inside the PLC. In addition, processing such as sending alert notifications directly via a Web API to in-house chat tools (Slack, Microsoft Teams, etc.) through Python's Requests library when a communication error occurs can be written with very simple code.

4. Technical benefits of PLC × Python

Being able to call Python easily from the PLC delivers overwhelming development efficiency and functional expansion, such as:

• Ultra-low latency with no communication: direct data exchange via shared memory or an internal bus eliminates communication delay as much as possible, making it possible to keep up with high-speed cycles.
• Dramatic reduction in development effort: countless open source (OSS) assets created by engineers worldwide in IT and data science, and Python code generated by AI such as ChatGPT, can be ported and reused directly on the FA shop floor.
• Simpler system configuration: external PCs and IoT gateways become unnecessary, saving space in the control panel, cutting hardware costs and improving reliability at the same time.

Conclusion: the ultimate synergy of real-time control (OT) and a flexible language (IT)

The approach of "using Python from the PLC" is the most realistic and powerful way to merge sequence control, which requires deterministic real-time behavior, with modern software that excels at non-deterministic, flexible data processing.

Some industrial PC-based controllers and advanced PLCs have already started running Python alongside control by incorporating Linux containers (Docker, etc.) or micro-runtimes. If this integration becomes standard, FA engineers will gain the strongest pair of wheels, "ladder that moves hardware" and "Python that handles data intelligently," and accelerate the intelligence of machines at an unprecedented pace.

The Future of Soft PLCs and Dedicated Hardware

A roadmap of "two-way evolution" driven by the pursuit of reliability and openness

1. Background: a paradigm shift in control platforms

The PLC (Programmable Logic Controller), which has supported factory automation (FA) for many years, has evolved as "dedicated hardware" with high reliability and robustness. However, with the rapid progress of IT and the DX of manufacturing, the "soft PLC (software PLC)," which implements PLC functions on general-purpose hardware such as industrial PCs (IPCs), is quickly gaining ground.

As a result, the FA industry is entering a realistic new era in which, rather than "everything being replaced by soft PLCs," dedicated hardware and soft PLCs "branch and evolve while coexisting," each leveraging its own strengths.

2. The essential value of dedicated PLCs: why they will not disappear

No matter how widespread soft PLCs become, dedicated PLCs will never be completely phased out. That is because, for production equipment that keeps running 24/7 in harsh environments, the following overwhelming advantages of dedicated hardware are indispensable.

• Extremely high real-time performance (deterministic operation): unlike general-purpose operating systems (Windows, etc.), there are no interruptions from background processing, and strict fixed-period scans at the microsecond level are fully guaranteed.
• Overwhelming reliability and environmental resistance: dedicated designs that withstand harsh factory environments, such as fanless construction, high noise immunity, vibration resistance and a wide operating temperature range.
• Long-term stable supply and maintainability: very little risk of being caught by OS end-of-life (EOL), so the same hardware and logic can keep running stably for 10 or 20 years.

In areas where reliability and real-time performance come first, such as ultra-high-speed motion control and interlock control for core lines where even a momentary stop is not allowed, dedicated hardware will remain the main player.

3. The innovation of soft PLCs: advanced IT functions condensed into one PC

On the other hand, the greatest strength of the soft PLC is the overwhelming extensibility and IT affinity that come precisely from the hardware being a general-purpose architecture (PC).

Processing that was difficult with conventional dedicated hardware can coexist and run seamlessly on the same hardware (one PC).

• Ladder engine and IT functions side by side: by running Linux containers or a Windows environment alongside the ladder engine that performs control, databases (SQL, etc.), AI inference models and web servers (dashboards, etc.) are all contained in a single enclosure.
• High-speed internal communication with no relay: control data and IT systems (Python, C#, Web APIs, etc.) are linked directly and quickly through memory space (shared memory or via a hypervisor), without communicating with external PCs or servers.
• Optimized edge computing: it becomes easy to store and analyze the large volume of raw data generated on site in a database right there, and visualize it in real time on a web screen for the shop floor (replacing HMIs, etc.).

4. The right tool for the right job

In future FA design, rather than pitting these against each other, a "hybrid structure" that uses each according to the system requirements will become mainstream.

For example, a hierarchical architecture that leaves ultra-high-speed control of individual machines to dedicated hardware, and adopts soft PLCs for the cell controller layer that aggregates data from multiple machines and handles data analysis and gateways to higher-level systems, is the most realistic and powerful solution.

5. Conclusion: the grand design of FA led by deeper dedicated hardware and evolving soft PLCs

Dedicated PLCs will evolve (deepen) by single-mindedly pursuing their identity of "reliability and real-time performance." Soft PLCs, on the other hand, will evolve outward, comprehensively adopting the latest IT trends (AI, databases, web technologies) and expanding the possibilities of control.

The future forms of FA development discussed so far, "text," "classes," "AI assistance," "cloud integration" and "Python," will show their true value precisely on top of this solid two-pole infrastructure of "ever-evolving dedicated hardware" and "flexible soft PLCs."

Web-Standard Languages for HMIs

Opening up screen design and transforming flexibility with HTML5 and JavaScript

1. Background: the limits of manufacturer-specific HMI design tools

When developing HMIs (touch panel displays) that visualize and operate factory equipment and lines, it is currently common to use the proprietary screen design tools provided by each control equipment manufacturer.

However, page-by-page screen design with these dedicated tools is reaching limits that cannot be ignored, given how fast modern UI/UX (user interface / user experience) is evolving and the need for efficient development environments for engineers:

• Vendor lock-in (manufacturer dependence): tool operation and specifications differ by manufacturer, so every hardware change means relearning and completely rebuilding the screens.
• Closed technical information: know-how about dedicated tools rarely circulates openly on the internet, making it hard to search for troubleshooting or advanced implementation methods.
• Rigid expressiveness and operability: smooth scrolling and dynamic animations (responsive design, etc.), which are taken for granted on smartphones and websites, are not easy to achieve with dedicated tools.

2. Solution: shifting to "web standards" with HTML5 and JavaScript

The breakthrough for these challenges is the approach of building HMI screens with the web-standard technologies HTML (HyperText Markup Language) and JavaScript, and having the HMI itself function as a "browser" that renders them.

It brings the same ecosystem as ordinary web development into the world of HMIs, without the need for dedicated design tools.

2.1 Intuitive UI with long pages and swipe operation

The fixed screen structure of "switching pages with buttons" gives way to a "long scrolling (swipe)" layout like modern smartphones and websites. This lets related motor parameters, trend graphs, alert history and more be placed seamlessly on a single screen (page), achieving an intuitive, highly visible operating environment (intuitive UI).

2.2 Advanced dynamic processing and versatility with JavaScript

If JavaScript (JS) runs on the HMI, you can freely graph raw data from the PLC in real time (using powerful open source libraries such as Chart.js), and implement complex animations, local temporary data caching and asynchronous integration with external Web APIs (such as fetching recipe data from a server).

2.3 Low-code / no-code HTML authoring tools

Since writing HTML/CSS/JS from scratch as text (code) is a high hurdle for every FA engineer, a realistic solution during the transition is for manufacturers or communities to provide "web-based screen design tools" that output web-standard HTML via intuitive drag and drop. Because the output is open HTML, later customization and code management with Git are also easy.

3. The overwhelming benefits of web-standard HMIs

Unifying screen design on web technologies brings substantial benefits to both developers and end users.

• Explosive acceleration of knowledge sharing: web technologies (HTML/JS) have the largest engineer population in the world. Countless technical resources such as implementation methods, bug fixes and design templates exist online, so solutions can be found right away by searching.
• Hardware abstraction (multi-device support): HTML screens can be displayed not only on dedicated HMIs but also in PC browsers in the factory office, on tablets on the floor or on smartphone screens, either as-is or automatically optimized (responsive).
• Flexible Git management and diffs: unlike proprietary binary screen data, HTML and JavaScript are pure text. Version control with Git and diffs of changes work perfectly.

4. Conclusion: "the future of HMIs" in step with the opening of controllers

With the "text-based PLC programs (mnemonics, classes)" and "rise of soft PLCs" discussed so far, the opening of the controller side (IT fusion) is steadily advancing. In step with this, the shift of the HMI side to web-standard technologies is an inevitable trend in the architecture of FA systems as a whole.

Some advanced manufacturers have already begun bringing PLCs with built-in web server functions and web-based HMIs (industrial web panels) with HTML5 runtimes to market. By removing the "frame" of dedicated tools and gaining the "free wings" of HTML/JavaScript, FA screen design will surely become more beautiful, more capable and, above all, a more enjoyable development environment for engineers.

HMI pages are generally created with each manufacturer's tool. If, instead of drawing page by page, you could create long HTML pages like website pages and swipe through them on the HMI, it would become general-purpose, and technical information could be found easily online. If you could create screens in HTML without manufacturer-dependent tools and have the HMI display them in a browser, flexibility would increase further. If JavaScript could also be used, it would be even better. If creating HTML is too high a hurdle, providing an HTML authoring tool would be a good idea.

[Summary] From Closed to Open

A grand design for next-generation FA development brought by the fusion of IT

1. Introduction: the paradigm shift of "openness" reaching FA development

As manufacturing DX (digital transformation) and smart factories are being called for, industrial software development is now at a dramatic turning point.
Until now, the Japanese FA industry has been supported by closed (manufacturer-specific) technologies integrated with hardware and the advanced craftsmanship of skilled engineers.
However, to respond quickly to rapidly changing market needs, cope with a worsening shortage of engineers and take in rapidly evolving IT (AI and the cloud), breaking away from the conventional "development style dependent on manufacturer-specific environments" is essential.

The seven themes of change discussed on this page are tied together by one strong axis: "opening up FA development (fusion with IT)."

2. Innovation in FA development across three layers

Organizing the discussion into three layers, "language and design approach," "advanced edge infrastructure" and "HMI (interface)," makes the next-generation FA architecture much clearer.

① Transforming the language and design approach (text, classes, AI assistance)

Converting graphical ladder diagrams into mnemonics (text) compliant with the international standard IEC 61131-3 is the first step toward bringing the benefits of modern software development to FA, such as version control and diffs with Git and knowledge sharing on social media.
Furthermore, implementing "classes (object orientation)" beyond function blocks (FBs) makes it possible to encapsulate complex controlled objects (servo axes, communication) cleanly as objects that combine data and processing.

Only when these "text" and "structured" assets accumulate on the web does the powerful future development assistance of "AI-generated ladder and safe code review" become reality.

② Advanced edge infrastructure (cloud, Python, soft PLCs)

On the controller (PLC) side, standard support for MQTT and REST API, the common languages of the IT world, is building an infrastructure that streams data directly to the cloud without gateways, enabling predictive maintenance and production analysis.
And if Python, the champion of data science, can be called directly, edge AI inference and OpenCV image processing can run inline with ultra-low latency, without going through an external PC.

"Soft PLCs" that absorb these vast IT functions (AI, databases, web servers) into a single enclosure, and "dedicated PLCs" that continue to guarantee overwhelming reliability: this "two-way evolution," with each used where it fits best, is the realistic and robust form of edge infrastructure going forward.

③ Transforming the interface (web-standard HMIs)

The final piece connecting these advanced systems with people (operators and engineers) is moving HMIs to web standards (HTML5/JavaScript).

Freed from the vendor lock-in of manufacturer-specific design tools, screen design can directly use the vast web technology assets developed around the world (templates, libraries, searchable knowledge). Smooth smartphone-like swipe operation and flexible deployment to multiple devices (tablets and PC browsers) will dramatically improve the user experience on the shop floor.

3. Overall assessment: what will be expected of FA engineers

The greatest value of these innovations is "freeing engineers from unproductive work and shifting them toward creating essential added value."

In conventional development, much effort went into deciphering manuals and routine work, such as checking specifications that differ by manufacturer, implementing tedious communication handshakes and brute-force screen drawing with dedicated tools.

But if AI generates the initial code, standardized classes and Python libraries are combined, and screens can be built flexibly in HTML, development effort will be cut dramatically. Engineers will be able to focus on truly creative work, such as higher-level "optimal architecture design for the whole machine," "refining advanced control algorithms" and "building business models that turn shop-floor knowledge into data."

4. Closing

"Draw in ladder, keep in text." "Use dedicated hardware for reliability and soft PLCs for flexibility." "Connect screens to the world with web standards."

The future described on this page is by no means an unreachable dream. At some advanced sites and controllers, this fusion has already begun.
When OT (operational technology) engineers gain the wings of IT, and IT engineers understand the value of real-time FA on the shop floor, Japanese manufacturing will truly evolve to the next stage. Shaping the new standard of FA development with your own hands: that is the greatest challenge, and the true joy, of FA engineering from here on.