Ce site utilise des cookies. En utilisant le site vous acceptez notre utilisation de cookies. Rejeter Plus d information

S'identifier
Software

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

Sauvegarde et restauration du programme PLC

Lors du premier lancement, il est nécessaire de définir un dépôt. Il s’agit généralement simplement du nom du dépôt. Ensuite, pour la configuration initiale, un projet TIA est requis. Ce projet définit le programme PLC d’un ou de plusieurs automates. Un seul dépôt peut gérer plusieurs projets TIA.
Chaque PLC est défini par son nom et son adresse TCP/IP. La configuration initiale lit le projet TIA et propose une liste des PLC avec leurs adresses IP. Un ou plusieurs d’entre eux peuvent être choisis pour les fonctions de sauvegarde et de restauration. Ensuite, il est possible de définir l’heure et la fréquence de sauvegarde. En général, cela se fait une fois par jour, la nuit.
En interne, le projet TIA est lu, décodé, et toutes les parties du programme sont envoyées dans le dépôt sous une forme lisible par l’homme. De plus, le projet TIA est enregistré pour des raisons de sécurité.

Chaque nuit, le PLC réel est vérifié pour détecter des changements. Si des modifications sont détectées, les éléments concernés sont lus depuis le PLC et envoyés dans le dépôt. Ceci est appelé un tag, identifié par l’horodatage et l’opérateur ayant effectué le changement.

Si certaines modifications, principalement effectuées le week-end, perturbent la production le lundi ou plus tard, le personnel de maintenance vérifie la liste des sauvegardes disponibles des derniers jours. Cela se fait via un navigateur. En général, la direction de l’équipe connaît la date de la dernière production stable. Elle choisit donc, par exemple, la version du mardi précédent. Ensuite, la fonction de restauration est lancée. Elle prend le projet TIA existant, lit toutes les modifications faites dans le PLC, copie le projet TIA et le met à jour avec les changements effectués jusqu’au mardi. Une fois terminé, il est téléchargé sur une machine avec TIA Portal installé — généralement un ordinateur du personnel de maintenance. Ensuite, TIA est lancé, le projet téléchargé est chargé, puis le PLC concerné est mis à jour et redémarré. La machine fonctionnera comme elle le faisait mardi.

Quelques détails sur la sauvegarde et la restauration. Si, pendant la nuit, la sauvegarde ne peut pas être effectuée, principalement parce que le PLC est indisponible, une alarme est générée. L’alarme est inscrite dans un journal de logs. Dans ce cas, l’envoi d’une notification par e-mail peut également être configuré. Alors, aucune sauvegarde ne peut être effectuée cette nuit-là.
Lors de la restauration, des vérifications de cohérence entre le projet TIA et le PLC sont effectuées. Si la configuration matérielle du PLC diffère, la restauration ne fonctionnera généralement pas correctement. Ceci est également vérifié dans les sauvegardes nocturnes et, si la configuration matérielle du PLC diffère, un avertissement est envoyé. En général, lorsqu’on modifie la configuration matérielle du PLC, un nouveau projet TIA doit être enregistré.

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.