Back

Contents

Blog

Version control for tracking and visualizing PLC code changes

23 Nov, 2022

2 min

Leandro Ribeiro

Leandro Ribeiro

Senior Industrial Full Stack Developer

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.

The-State-of-Developer-Ecosystem-2021
Image and data from The State of Developer Ecosystem 2021 report

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.

Screenshot-2022-11-23-at-21.59.16-2048x1263

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.

Screenshot-2022-11-23-at-21.58.42-2048x1269

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.

Screenshot-2022-11-23-at-21.42.06-2048x1268

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.

Stay up to date. Subscribe for our latest news.

subscribe icon