Bringing closed-loop automation from theory to practice
What is Closed-Loop Automation?
Closed-loop Automation is performing/automating a self-adaptive output process based on meaningful insights derived from continuous data collected by a system without human interference. In other words, automatically bridging the gap between Data → Insight and Insight → Action. Although this concept is well-recognized in academia as “self-adaptation”, it has yet to be implemented in practice.
In Closed-loop Automation, the necessary actions are identified based on knowledge and input information. Thus, data is the critical component. With good data and robust algorithms, systems can run without human intervention. According to IBM, Closed-loop Automation results in improved reliability, increased productivity, and a reduced mean-time to resolve incidents.
The heart and brain of industrial automation
Programmable Logic Controllers (PLCs) are industrial computers controlling various processes in manufacturing and other automation environments, often called the heart and brain of industrial automation. Factories use hundreds or thousands of PLCs in their day-to-day operations. These operations, their operating conditions, or the environment around them may change over time. When they do, these PLCs need to be reprogrammed to adapt to these changes. The large number of PLCs, the differences between vendors, and their lack of connectivity make it challenging to manage and keep track of projects deployed to every individual PLC.
For example, during a variant change of product on an assembly line, the Automation Engineer needs to change the PLC code on some or all PLCs connected to the machines on that line to produce that variant. This results in production downtime.
A blog from manufacturing.net indicates that downtime is the number one reason for loss of production, resulting in factories losing up to 20% in total productivity. Downtime in factories costs up to $250,000 per hour, at an average of more than $2 million per downtime event. 
Can this downtime be reduced to merely a few minutes? Can a system collect data about the change in operating conditions, automatically generate updated PLC codes and projects, and deploy it to the PLCs to adapt to these changes?
Closing the loop with TechOps from Software Defined Automation
Software Defined Automation is bringing closed-loop automation from theory to practice. Our Team of Engineers has synchronized two motor speeds to demonstrate the adaptation of PLC configurations and auto-generation of PLC projects in response to changes detected through real-time data insights using cameras, programmatic upload of PLC projects to the cloud and automated deployment using APIs, all powered by SDA TechOps.
SDA TechOps is a cloud-based PLC management platform for conventional and virtual PLCs, across different vendors. It enables uploading, downloading, and versioning of PLC projects and automated code deployments directly from the cloud to PLC without opening vendor-specific IDEs.
The setup consists of the following components:
- Two SIMOTICS S-1 FL6 servo motors driven by SINAMICS V90 servo drives. The master motor is controlled by a Siemens SIMATIC S7-1200 PLC which can change the speed of the motor in increasing steps of 10rpm with the help of a button. The follower motor is controlled by a CODESYS SoftPLC (Control Win V3) which is linked to the SDA console via a preconfigured gateway.
- Two high-resolution cameras monitor the physical process and provide data about the speed of the motors.
- A vision detection model that calculates the RPM of both motors using OpenCV library and detects the difference in speed.
- CODESYS “scriptengine” module for accessing CODESYS APIs to use functionalities like importing and exporting openXML files and generation of new project files.
- The Software Defined Automation platform provides solutions like SDA TechOps to link and manage PLCs and PLC projects and enables the “Silent Deploy” feature.
- A python program (Main Program) functions as a state machine to integrate all the above components and controls the entire process.
The main goal of this demo is to synchronize the speed of both motors if a difference in speeds is detected by the vision detection cameras, auto-generate PLC code and projects, and programmatic upload and deployment of these projects from cloud to physical PLCs, hence demonstrating the closed-loop process.
Putting it into practice
The figure below shows the elaborate version of the MAPE loop which has been used in this demo to put theoretical concepts into practice.
The entire process is divided into 3 stages: speed detection stage, project file generation stage and execution stage.
The master motor runs at a defined speed (eg. 10 RPM) and the follower motor is stationary. The main program is executed and real-time speed data is collected from both motors using the OpenCV python modules. The difference in speed is detected between the two motors (in this case difference of 10 RPM) and the value of master motor speed is returned to the main program.
A CODESYS server which runs the CODESYS IDE is executed asynchronously which facilitates the use of CODESYS “scriptengine” and CODESYS APIs. Using these APIs we can open an existing project and extract the openXML file of the PLC code. This XML file is programmatically modified with the new speed value, imported back into the CODESYS IDE and a new project file is generated using APIs. (Auto-generation of PLC code and project).
This newly generated project file is uploaded to the SDA TechOps using REST API calls and is linked to the CODESYS SoftPLC. The “Silent Deploy” feature is used to programmatically deploy this project to the CODESYS SoftPLC which controls the follower motor.
The closed-loop process is finished and both the motors now run at the same speed (in this case 10 RPM). The cameras detect the same speed on both motors and acknowledge the completion of the synchronization process. The speed detection loops until a new difference in speeds of the two motors is detected and executes the above processes again.
Closed-loop Automation detected speed difference between the two motors, auto-generated PLC code and PLC project file, programmatically uploaded and deployed projects from cloud to the PLC using APIs and completed the synchronization process in less than 5 minutes without human interference.
These processes, if done manually would have taken hours to complete and increased downtime and costs.
A set of 10 experiments for different master motor speeds were carried out and following results were achieved.
The total time required for each experiment is calculated and represented in the histogram below.
The graph shows that most of the experiments were completed in the time range of 185 seconds to 205 seconds, which is around three to three and half minutes, with some outliers.
The average of total time required to complete the above 10 experiments is shown below.
The calculated average time that is required to complete this closed-loop process is 3 minutes 17 seconds.
This shows that such resilient systems which rapidly adapt to changing operating conditions are needed in today’s industries to facilitate increase in overall productivity and efficiency of factory operations and better management of its systems.
Closed-loop Automation can be implemented in industrial processes, like commissioning a machine, synchronizing two or more processes, scheduling, process optimization and many more.
Start now by 1. Identifying undifferentiated, repeatable process adaptations. 2. Implement a detection mechanism (e.g. visual) 3. Build an automated PLC re-programming loop to bring process adaptations back to the control layer.
Get in touch with us if you want to learn more about the PLC re-programming loop.
 Sharath Prasad, Dushyant Behl, Juel Raju, Trey Lewis, Building AI-driven closed-loop automation systems, July 2021, IBM Developer. https://developer.ibm.com/articles/an-introduction-to-closed-loop-automation/
 Talmage Wagstaff, Minimizing the Effect Of Downtime, June 2021, Manufacturing.net. https://www.manufacturing.net/operations/blog/21533375/minimizing-the-effect-of-downtime