Git-based version control for tracking and visualizing PLC code changes

Code versioning is a standard practice in modern software development but is not often implemented in the industrial automation field. As more industrial processes are automated with Programmable Logic Controllers (PLCs), code versioning becomes critical to implement. Code versioning can reduce the time required for machine commissioning and code modifications, prevent downtime and help simplify machine maintenance.

PLC software development can take up to 12 months for large projects. Automation engineers might be added to the group or leave the project during this period. Thus, it is critical to have control and visibility of the code version history, as missing version history can make the code development process harder. 

In an actively operating machine, it is critical to provide visibility to the recent code changes to the maintenance team. Typical code modifications include bypassing a certain logic, modification of instruction block(s) to match the settings of a new external device, adjustment of internal operating parameters, hardware change, firmware upgrade, etc. If these modifications are not available to the maintenance team, downloading an outdated code may result in unintended operation, which could lead to injury at the plant. 

Version control serves as the machine history and is highly beneficial in a regulated environment, such as the manufacturing industry. Depending on the range of implementation, it can tell the technical events made to the code. For example, if the system is malfunctioning, the maintenance team can understand which change impacted the system’s performance by reviewing the change history. 

Version control may also function as the operational log of the system. For example, it can show which part frequently bogs down and the typical solution that can bring the system back to working condition. If the system is a multi-use, multi-product machine, version control may also dictate which program to use per product run.   

What’s the status quo in PLC code development?

There is a number of existing solutions in the market that offer Integrated Development Environments (IDEs) where PLC, Human Machine Interface (HMI), and Supervisory Control and Data Acquisition (SCADA) engineering environments are within the same software package. Some even feature a version trail tool. However, IDEs are vendor-specific and some require licenses. 

Currently, in the industrial automation field, often the implementation of version control is done by copying the same project repeatedly and by making changes to the file’s name. System integrators or machine builders sometimes develop a proprietary system, while manufacturers typically store the PLC code to their workstations within specific folders with relevant identification to the revision. This approach to version control heavily relies on the discipline of an individual automation engineer who modifies the code. It doesn’t provide visibility on who made the revision, when and why. Even if the programmer has time to specify the reason(s) for code modification, it is a tedious task due to the lack of appropriate tools that help automate version control. In addition, the code development is done offline, which limits co-engineering and co-development. 

When and how to implement version control?

Code versioning starts with the first written line of code and runs throughout the entire lifecycle of the control code – including post-testing, commissioning, and active plant service.

The initial version control responsibility lies with the system integrator or OEM, covering detailed engineering, testing, commissioning, and end-of-warranty contract. After this, the primary responsibility is transferred to the end-user or client managing the entire operational stage of the system. The system integrator or machine builder can sometimes maintain the code during the warranty period and after, if contracted.

Once the machine is fully operational, it is typical for the maintenance team to modify the code for various reasons. One common event is during an instrument failure that requires immediate replacement to avoid operation interruption and shutdown. For example, if the failed device has no available replacement, a typical maintenance solution is bypassing the portion(s) of the code dependent on the failed device. 

Such events typically lead to untracked revisions, especially in 24/7 operations, when for example, the night shift has made changes to the code and the morning shift has no visibility into it. In addition, the version of the code maintained by an integrator or OEM becomes outdated.

SDA DevOps provides Git version control for PLC code, allows backup and version projects in the cloud, and co-engineer with other PLC developers. It does not require multiple IDE licenses and allows downloading the PLC code to different workstations while updating every instance of the code via a sync functionality.

With SDA DevOps, every developer can have a local copy of the repository on their respective programming workstations. The software detects, indicates who made the change, and describes what was modified via a comment message. 

Leandro Ribeiro
Senior Industrial Full Stack Developer
Software Defined Automation

When automation engineers commit the code, the latest changes are sent to the master repository. SDA DevOps detects code merge and has the functionality to approve or reject the proposed modification. 

For system integrators and OEMs, version control can reduce code development time and lower project implementation costs. For Manufacturers, version control reduces the dependency to 3rd party support, which may lower operational and maintenance costs of the process or machine. Ultimately, with an updated code available at any moment in time, downtime may not be prevented; however, it can be effectively shortened due to the availability of an updated code which functions as a system restore point. 

With SDA’s DevOps approach, the local client for Windows workstations facilitates the use of Git locally to automatically sync changes made to PLC projects locally to the SDA platform. Engineers can backup and version projects in the cloud, design projects remotely, co-engineer and collaborate. 

Start now and create an account to get visibility into all your PLC projects and changes.

Dear vPLC, how real-time are you?

Note: This article is a condensed version of the scientific paper we published at the IEEE IES International Conference on Emerging Technologies and Factory Automation (ETFA), Stuttgart, Sept. 2022 [9]

Modernizing the factory automation stack requires more than an update of the latest PLC models. Instead, a paradigm shift towards software-defined automation is required [1],[2]. The design and implementation of flexible manufacturing systems for individualized products are crucial for competitive production systems of the future [3],[4],[5]. In such systems, reconfiguration or redeployment of industrial automation systems can be done for every piece, the application of machine learning and artificial intelligence (AI) algorithms is essential, and full-loop feedback systems enable self-optimizing production systems.

Programmable Logic Controllers (PLCs) are widely used throughout industrial automation due to their determinism, quick response times, and robustness. However, current PLCs, along with the way the industry is structured, can’t support future scaling needs [6],[7]. Hardware/Software integrated PLCs do not support resource-demanding tasks, such as algorithms based on machine learning and artificial intelligence. Furthermore, hardware-based PLCs imply individual maintenance and hardware costs, as every single technical process regularly includes an individual PLC for each subsystem [7]. Modern control systems need to meet requirements for operational technologies and information technologies.

Although there have been many incremental innovations to PLCs over the past decades, these have been focused on the integration of improved hardware components, such as more operations per second or newer and faster communication protocols, rather than structural changes to the programming model or the architecture of PLCs.

Figure 1: In a software defined automation, virtual PLCs can be used to control industrial assets in the same way as conventional PLCs do. A COTS server located on the edge can host multiple virtual PLCs to control assets in real-time. Virtual PLCs can be managed and monitored from a cloud instance.

Uncoupling of hardware and software not only allows scaling but also helps to overcome supply chain challenges with proprietary PLC hardware due to the vast availability of standard x86 server hardware. The term virtual PLC refers to a soft PLC that runs within a virtual machine managed by a real-time hypervisor in a commercial-off-the-shelf (COTS) server. Servers and computers can offer enough resources to fulfill the functions of PLCs, Human-Machine Interfaces (HMIs), and programming terminals together [8]. A server hosting virtual PLCs that communicate with the shop floor and cloud  (see Fig. 1). Coupling the cloud and shop floor further allows the implementation of software-based PLC operations (Ops), as well as data collection and use of advanced machine learning algorithms, while still satisfying deterministic real-time requirements. Virtual PLCs help overcome the limitations of hardware-based PLCs by offering more flexibility, better resource usage, scalability, and lower costs.

The virtual PLC implementation portrayed in [9] was done using a barebone server, VMWare’s ESXi 7.0 hypervisor, Linux Debian 11, CODESYS SoftPLC runtime, and EtherCAT.  As virtualization has the outlined benefits, the million-dollar question is: Does it also fulfill real-time requirements in discrete automation of around 10ms? To measure the real-time performance, we implemented a Virtual PLC (vPLC) architecture and executed extensive performance tests [9]. The results indicate that virtual PLC is a viable option for important domains of factory automation, where response times between 5-10 ms are acceptable [10].

Figure 2: Average response times from input to output for rising and falling edges at the input. The horizontal error bars represent the minimum and maximum recorded values.

So, what do we learn from this focused research? Dear vPLC, you are real-time enough for most discrete factory automation applications!

  • The measured maximum response times suggest that the vPLC can be used in areas of industrial automation in factory automation where response times between 5-10 ms are acceptable.
  • Task execution times of the PLC runtimes in the server are within the microseconds range. Therefore, improvements in networking speeds will bring vPLCs down to the motion control range <1ms. [Refer to reference 9 in the full paper].


[1] J. Waltl, Unchain the ShopFloor through Software-Defined Automation, May 2018. [Online]. Available: (visited on 04/05/2022).

[2] H. Forbes, The End of Industrial Automation (As We Know It), Dec. 2018. [Online]. Available: (visited on 04/28/2022).

[3] Y. Koren, The Global Manufacturing Revolution: Product-Process-Business Integration and Reconfigurable Systems. New Jersey: John Wiley & Sons, Ltd, 2010, pp. 227–252.

[4] I. Garbie and A. Garbie, “Outlook of requirements of manufacturing systems for industry 4.0,” in 2020 Advances in Science and Engineering Technology International Conferences (ASET), Dubai, Feb. 2020, pp. 1–6.

[5] S. Vaidya, P. M. Ambad, and S. M. Bhosle, “Industry 4.0 a glimpse,” Procedia Manufacturing, vol. 20, pp. 233–238, 2018.

[6] R. Langmann and M. Stiller, “Cloud-based industrial control services: The next generation PLC,” in Online Engineering & Internet of Things. Lecture Notes in Networks and Systems. Cham: Springer International Publishing, 2018, vol. 22, pp. 3–18.

[7] P. Gaj, J. Jasperneite, and M. Felser, “Computer communication within industrial distributed environment a survey,” IEEE Transactions on Industrial Informatics, vol. 9, no. 1, pp. 182–189, Jul. 2013.

[8] E. R. Alphonsus and M. O. Abdullah, “A review on the applications of programmable logic controllers (PLCs),” Renewable and Sustainable Energy Reviews, vol. 60, pp. 1185–1205, Feb. 2016.

[9] D. Perez, L. Prenzel, J. Waltl and S. Steinhorst, “How Real (Time) Are Virtual PLCs?”, in IEEE IES International Conference on Emerging Technologies and Factory Automation (ETFA), Stuttgart, Sept. 2022.

[10] PROFIBUS International, “PROFINET Real-Time Communication,” Tech. Rep., 2013.

Josef Waltl, Diogenes Javier Perez