Products PlcGit, the working and goals

PlcGit has multiple functionalities

PLC program backup and restore
Check and merge differences between versions of the PLC software
Manage PLC program code in a distributed development team

The following description is an example for the Siemens S7 1500 PLC series using the Siemene TIA Portal PLC programming software

PLC Program Backup and Restore

On the first run a repository needs to be defined. This is mostly the name for the repository. Then, for the initial setup, a TIA project is needed. This project defines the PLC program of one or multiple PLCs. Multiple TIA projects can be handled by one repository.
Each PLC is defined with its name and its TCP/IP address. The initial setup reads the TIA project and offers a list of the PLCs with their IP addresses. One or multiple of them can be chosen for the backup and restore functionality. Then the backup time and backup rate can be defined. Mostly this is once a day at night.
Internally the TIA project is read, decoded, and all the program parts are sent to the repository in a human-readable form. Additionally, the TIA project is checked in for security reasons.

Now every night the real PLC is checked for changes. If some changes are detected, the affected elements are read from the PLC and sent into the repository. This is called a tag, identified by the timestamp and the worker who did the change.

Now if some changes, mostly done on a weekend, may disturb production on Monday or later, the maintenance personnel check the list of available backups from the last days. This is done in a browser. Normally the shift management knows the date of the last stable running production. So it chooses, for example, the version from the last Tuesday. Then the restore functionality is started. This takes the existing TIA project, reads all changes made in the PLC, copies the TIA project, and updates it with the changes done until Tuesday. When finished, it is downloaded to a machine with TIA Portal installed — mostly this is a machine from the maintenance personnel. Then TIA is started, the downloaded project is loaded, then the affected PLC is updated and restarted. The machine will work as it did on Tuesday.

Some details about backup and restore. If during the night the backup cannot be done, mostly because the PLC is unavailable, an alarm is generated. The alarm is written to a logging station list. An email notification in this case can be configured. Then no backup can be done that night.
On restore there are some checks for TIA project and PLC consistency. So if the PLC hardware configuration differs, mostly the restore will not work properly. This will also be checked in the nightly backups, and if the PLC hardware configuration differs a warning is sent. Normally, when changing the PLC hardware configuration, a new TIA project needs to be checked in if this happens.

Check Differences Between PLC Program Versions and Merge

After an emergency restore or for other reasons the maintenance personnel can check for changes between different detected changes or against the original TIA project content. This is also done in a browser.
So the repository is chosen from the list, then a PLC. The view is similar to the TIA Portal with a list of the PLC blocks. Changed blocks are marked. Then a (changed) block will be chosen. The block content will be displayed in the browser similar to TIA Portal as KOP/FUP/SCL/Graph. The block is shown twice, one and the other block. Detected changes are marked visibly. PLC program code is programmed in rungs, one rung only is shown. Changed rungs are marked in the list of rungs.

Merging means that the user can now take complete blocks from one version to another, or complete rungs. Or in a rung, individual elements or element groups can be used for merging.
Testing this is done as in restores: Generate TIA project, download the project, open TIA, load the project in TIA, and afterwards into the PLC.

Manage PLC Program Code in Distributed Software Development Teams

For software development, normally no PLC exists. Multiple persons in the team are working on different parts of the PLC software. The PLC block selections and merge functions are needed only.
In this case multiple TIA projects can exist. They can be checked into a repository. For combining the code the blocks can be chosen and merged into one resulting TIA project. This can generate various merge conflicts. Such elements are marked. Then some manual work can solve the issues such as renaming some variables or blocks, or renumbering blocks. Typically the structures used in the distributed development team are different. A possible solution is the creation of a new structure in the merge containing all of the variables from the team members. But other solutions are possible also.
Different TIA versions in the team are mostly no problem. The merge from lower to higher TIA versions will always work. Stepping down can be possible if the affected PLC blocks do not use special functionality the older TIA cannot handle.
The only thing which cannot be merged is hardware configurations. They are always incompatible.