Version Control for PLCs

Data management for automation

There is one general truth that applies to automated production: The higher the level of automation in production, the more critical it is to correctly match all process-related elements. Not only is this requirement of great significance when commissioning a system or plant but also during ongoing production. Constant optimization and fine-tuning of production processes will be required to be able to react to growing and changing demands for product variants, efficiency, and product quality.

This makes it necessary to track each optimization without effort and conveniently retrieve any document describing changes that have been made. Of course, not only the latest change is relevant but also keeping track of past changes, starting with the initial version and covering all subsequent modifications to the system. This is particularly true in a strictly regulated manufacturing environment where corresponding documentation is a must, which includes even legacy production versions that were used a long time ago. To meet these requirements, AUVESY has developed "versiondog," a data management system that can be used for creating and tracking software versions for PLCs, NC programs, visualization systems, robots, frequency converters, and other automation components, regardless of their manufacturer.

The versiondog system is based on three pillars which are explained in greater detail below:

Centralized Data Storage

Essentially, it is the job of a version management system to provide exactly one valid version of a data set (NC program, PLC program, or configuration file). This means that only one version can be valid at a given time. How does this translate into real-world conditions for the maintenance of an automated production plant? Daily maintenance alone makes it clear that providing a consistent and unique current version of a data set brings about several challenges, especially if activities are performed under time pressure or with limited resources. Some examples:

  • Usually, more than one engineer is involved in the maintenance and configuration of software programs controlling a production process.
  • Not every change is immediately successful and free of harmful side effects. Even a well-meant optimization will first have to be validated before approval is granted for the changed program.
  • Sometimes multiple changes and optimizations to a program are required, and this will have to be dealt with by numerous software developers coming from different areas of responsibility.

It becomes clear that consistency and sustainability can never be achieved by undocumented manual interventions or individual versioning and housekeeping. It is precisely at this point that the versiondog system comes into play:

  • The currently valid version of a program is the latest version that was centrally stored on the server system. Generally, it can be said that exactly one current version can exist.
  • Access to the currently valid version in the central server archive is granted by a request procedure referred to as "Check-Out." Optimizations of the automation program are released by writing back the new version onto the server ("Check-In").
  • Simultaneous access to a program by multiple users, who,in the worst case, do not know of each other, will be prevented. This is ensured by an option referred to as "exclusive editing" of a project.
  • The project data are kept in the server archive in their original data format. In an emergency, the data can also be accessed directly (as a zip archive in a folder structure).

Versioning and Change History

To be able to keep track of changes to the production process in a reliable, seamless manner, it is required to document the reason, the time and the responsibility for each modification to a software program. This may sound easy and self-explanatory, but in reality, it represents a challenge. Perhaps a major reason for this is the fact that the process of documenting a change to a program is not regarded as a mandatory part of the job but as bothersome extra work that is neglected in most situations.

Therefore, documentation of program changes needs to be understood as a part of the change process. So, versiondog not only takes care of all administrative steps including centralized storage of the changed program as the currently valid version in the central server archive (see above) but also supports the user and makes sure that all users double-check their changes to the project and document all changes without effort.

It is exactly here that the so-called Smart Compare of versiondog can prove their usefulness. They adopt the project presentation depending on the managed automation projects. In this way, the user obtains a loss-free and recognizable display of information on project changes in a familiar format, i.e., in exactly the same structuring and representation as known from the development environment of the manufacturer. All differences between the two versions are displayed to the user in detail (e.g., in graphical, table or text format). The system supports the documentation of changes before the edited version is released as a new current version in the server archive via the Check-In procedure.

Based on end-to-end traceability of all changes to a PLC program, versiondog provides the following advantages by retrieving information from the change history:

  • From the initial version to the currently valid version, all data sets including any version comments and a summary of changes are available to the user.
  • There is complete documentation on who has changed what at which point in time, what was the reason for the change and what the change looks like in detail (audit trail).

It can be tracked which version was in use at any given time.

Monitoring of programs in automation devices

In order to ensure consistent quality and productivity of manufacturing processes, it is important that all modules involved are up-to-date regarding their programs and their parameter settings. To achieve this, the following prerequisites must be fulfilled: Firstly, the latest version of a given program must be known. Secondly, it must be ensured that the automation devices are loaded with exactly those program versions that are supposed to run on them according to the specification.

With versiondog, the first question for the latest version can be answered right away: It is exactly the version that has been stored centrally in the server archive (see above). Now, a monitoring task (also referred to as "job") that has to be executed cyclically can be stored for each data set. For example, a daily routine can check whether the program in the controller still corresponds to the current or latest version in the server archive. If a deviation is found, the responsible person can be informed directly via e-mail.

Monitoring the programs running on automation devices utilizing versiondog leads to the following consideration: If it can be made sure that all devices involved in a manufacturing process operate with exactly the same project version and parameter setting – thus matching the current version in the server archive, the following advantages will result:

  • Optimizations resulting from an analysis of the process can be directly adopted in the project because the current version of the program and the configuration data are known for each automation device.
  • Should a change to the system be discovered, the message issued by versiondog will systematically cause a reaction: It has to be checked what has changed and whether the change can be identified as an added value optimization. It can also be determined whether the change is a desired/planned change and whether the functional safety of the plant is affected by the change.
  • As the latest project version of a device is known, disaster recovery procedures can be performed immediately to minimize plant downtime.

Summary

In summary, versiondog provides the currently valid software version of a production plant to enable further optimization or modification. The resulting changes, including any comments, are recorded and stored safely. This not only includes changes made by in-house staff but also changes made by external service providers or plant engineers. At the bottom line, this results in a complete change history of your production plant. Even undesired changes to the program that have been caused accidentally, inadvertently or intentionally (e.g., by cyber-attacks) will be recorded. versiondog thus helps to provide a database for changes in the production plant as well as the documents required for audits. Last but not least, the system constitutes one more piece needed to complete the data security and data safety jigsaw puzzle in production facilities and manufacturing companies.

Go back