Wersjonowanie TIA Portal w Git zwykle rozbija się o ten sam problem: projekt TIA Portal to plik binarny. Repozytorium pokaże więc, że plik się zmienił, ale nie wyjaśni, co konkretnie zostało zmienione. Dla praktyka, który utrzymuje maszyny, to realny kłopot – a nie tylko niedogodność narzędziowa.
TIA Project Server pomaga w zarządzaniu kolejnymi wersjami projektu. Przechowuje je, blokuje pliki i pilnuje kolejności pracy. Nie daje jednak prostej odpowiedzi na pytanie: „Co zmieniło się w projekcie między wtorkiem a czwartkiem?”. Można opierać się na opisach wersji, ale ich jakość zależy od systematyczności wszystkich osób pracujących z projektem.
Chciałem sprawdzić, czy da się uzupełnić ten proces o czytelną historię zmian. Zbudowałem więc proof of concept narzędzia, które eksportuje zawartość projektu TIA do postaci nadającej się do wersjonowania w Git. W tym artykule opisuję założenia, największe trudności i wyniki dotychczasowych testów.
Skąd wziął się ten pomysł
Punktem wyjścia były sytuacje, które regularnie pojawiają się przy utrzymaniu maszyn.
Pierwsza to awaria i pytanie: „Co właściwie jest teraz wgrane?”. Ustalenie, jaka logika oraz konfiguracja sprzętowa działały na sterowniku w konkretnym dniu, zwykle wymaga otwierania kolejnych wersji projektu w TIA i ręcznego ich porównywania.
Druga sprawa to zmiany sprzętowe. Ktoś zmienił adres IP, dołożył moduł albo przestawił adres urządzenia w sieci PROFIBUS. Przy kilku sterownikach, stacjach rozproszonych i rozbudowanej sieci odtworzenie, kto wykonał zmianę i kiedy, potrafi być bardzo trudne.
Trzeci problem dotyczy przeglądu zmian. Projekty HMI oparte na plikach można umieścić w repozytorium i przejrzeć przed wdrożeniem. Z programem PLC jest trudniej, ponieważ sam plik projektu nie daje materiału do sensownego code review.
We wszystkich tych przypadkach brakuje tego samego: historii, którą można szybko przeczytać i zrozumieć bez otwierania kilku kopii projektu.
Kilka pojęć związanych z Gitem
Do zrozumienia dalszej części wystarczą cztery podstawowe pojęcia.
- Git to system kontroli wersji. Zapamiętuje kolejne stany katalogu z plikami i pozwala wrócić do dowolnego z nich. Najlepiej działa z plikami tekstowymi.
- Commit jest zapisanym stanem projektu w określonym momencie, wraz z opisem zmiany i informacją o autorze.
- Diff pokazuje różnicę między dwoma commitami: linie dodane, usunięte albo zmienione. Właśnie tego brakuje w przypadku binarnego pliku projektu TIA.
- Branch i pull request pozwalają przygotować zmianę na osobnej gałęzi, poddać ją przeglądowi, a dopiero później dołączyć do wersji głównej.
Tekstowa reprezentacja projektu TIA
Zamiast próbować wersjonować sam plik projektu, eksportuję jego zawartość przez TIA Openness. Plik binarny nadal może pozostawać w TIA Project Server, natomiast do Gita trafia jego tekstowa reprezentacja.
Obecnie obejmuje ona:
- bloki LAD, FBD i SCL jako Simatic Source Documents – w TIA Portal V21 również bloki graficzne można wyeksportować do czytelnego tekstu zamiast XML;
- UDT oraz tabele tagów zapisane jako SimaticML;
- konfigurację sprzętu wyeksportowaną przez CAx/AutomationML i przetworzoną do uporządkowanego pliku YAML;
- elementy programu panelu HMI, między innymi ekrany, tagi i połączenia;
- sygnatury bloków F, przeznaczone wyłącznie do kontroli zmian.
TIA Openness jest interfejsem programistycznym TIA Portal. Pozwala zewnętrznemu programowi otworzyć projekt i wyeksportować jego zawartość bez ręcznego przeklikiwania się przez interfejs TIA.
Po eksporcie powstaje zwykłe repozytorium: można przeglądać historię, pracować na gałęziach i przygotowywać pull requesty. Sam projekt TIA nie zmienia przy tym swojego formatu.
Czytelny diff konfiguracji sprzętowej
W przypadku programu część problemu rozwiązuje sam eksport. SCL od dawna ma postać tekstową, a TIA Portal V21 pozwala w podobny sposób potraktować także bloki graficzne. Więcej pracy wymagała konfiguracja sprzętu.
Zmiana adresu IP, dodanie modułu albo przestawienie adresu PROFIBUS powinny być widoczne w historii w sposób zrozumiały dla człowieka. Surowy eksport CAx/AutomationML jest do tego mało wygodny, dlatego narzędzie przekształca go do uporządkowanego YAML-a, a następnie porównuje zmiany na poziomie znaczenia.
W efekcie historia może zawierać komunikaty podobne do tych:
PLC-01: zmieniono adres IP interfejsu X1 z 10.2.0.1 na 10.2.0.50
Stacja IO: dodano moduł DI 4x24VDC w slocie 3 (6ES7 221-3BD30-0XB0)Taki zapis jest czytelny nie tylko dla programisty. Może z niego skorzystać również automatyk z innej zmiany albo kierownik utrzymania ruchu, który chce szybko ustalić zakres modyfikacji.
Największy problem: powtarzalność eksportu
Najwięcej czasu nie zajęło samo uruchomienie eksportu ani przygotowanie widoku różnic. Kluczowe okazało się doprowadzenie eksportowanych plików do stabilnej postaci.
TIA potrafi zapisać ten sam, niezmieniony projekt w nieco inny sposób przy kolejnych eksportach. W plikach pojawiają się między innymi data eksportu, data kompilacji i czas ostatniej modyfikacji bloku. Wystarczy jedno takie pole, aby Git pokazał zmianę mimo tego, że nikt nie zmodyfikował programu ani konfiguracji.
Gdyby taki eksport był wykonywany codziennie, repozytorium szybko wypełniłoby się zmianami pozbawionymi znaczenia. Po pewnym czasie użytkownicy po prostu przestaliby ufać historii.
Dlatego pomiędzy eksportem a zapisem w Git działa normalizator. Usuwa pola zależne od czasu i porządkuje strukturę plików. Podstawowy test brzmi: dwa eksporty niezmienionego projektu muszą dać pusty diff.
W praktyce wykonuję snapshot projektu, nie wprowadzam żadnych zmian i uruchamiam snapshot ponownie. Jeżeli narzędzie chce wtedy utworzyć commit, eksport nie jest jeszcze wystarczająco stabilny. Podczas pierwszego testu przyczyną fałszywych zmian było pojedyncze pole z datą eksportu dodawane do każdego pliku.
Odtworzenie projektu z wybranego commita
Samo przeglądanie historii jest przydatne, ale chciałem też sprawdzić możliwość powrotu do wcześniejszego stanu. W obecnej wersji narzędzie odczytuje wskazany commit i na jego podstawie odtwarza program oraz konfigurację sprzętową w projekcie TIA.
Ta część ma znaczenie również dla pracy z gałęziami. Po zaakceptowaniu i scaleniu zmiany stan zapisany w Git musi dać się przenieść z powrotem do TIA Portal. Bez tego repozytorium pełniłoby głównie funkcję dokumentacyjną.
Zapis do projektu jest najbardziej ryzykowną operacją wykonywaną przez narzędzie, dlatego zastosowałem trzy zabezpieczenia:
- przed zapisem zawsze powstaje plan zmian;
- przed każdą operacją zapisu tworzona jest kopia zapasowa z datą i czasem;
- bloki bezpieczeństwa pozostają nietykalne.
Sygnatury bloków F są zapisywane w historii, ale tylko w celu wykrywania zmian. Narzędzie nie ma ścieżki importu programu safety. Eksport i ponowny import takich bloków mogłyby unieważnić zbiorczą sygnaturę F oraz wymagać ponownego odbioru bezpieczeństwa. Tego rodzaju operacja nie powinna odbywać się automatycznie w tle.
Co udało się sprawdzić
Projekt jest nadal na etapie proof of concept. Na rzeczywistym projekcie przetestowałem:
- wykonanie snapshotu całego projektu;
- uzyskanie pustego diffa dla dwóch eksportów bez zmian;
- semantyczne porównanie konfiguracji sprzętowej;
- odtworzenie wybranego snapshotu;
- prostą aplikację okienkową;
- panel webowy z historią stacji.
Test odtworzenia dał obiecujący wynik. Po wykonaniu eksportu i commita zaimportowałem zapisany stan z powrotem do TIA, a następnie ponownie go wyeksportowałem. Otrzymana reprezentacja tekstowa była identyczna z pierwotną co do bajtu.
Zakres testów jest na razie ograniczony. Nie sprawdzałem wersji TIA Portal starszych niż V21 ani zachowania narzędzia na dużych projektach. Dotychczasowe próby obejmowały jeden sterownik PLC, jeden panel HMI i kilka modułów. Wyników nie należy więc jeszcze traktować jako potwierdzenia działania dla każdej konfiguracji TIA.
Najczęstsze pytania (FAQ)
Czy trzeba rezygnować z TIA Project Server?
Nie. Plik binarny nadal może żyć w TIA Project Server, a do Gita trafia równolegle jego stabilna reprezentacja tekstowa. Oba narzędzia się uzupełniają: Project Server pilnuje kolejności pracy, Git daje czytelną historię zmian.
Co dokładnie trafia do repozytorium?
Bloki LAD, FBD i SCL jako Simatic Source Documents, UDT i tabele tagów jako SimaticML, konfiguracja sprzętu jako uporządkowany YAML, elementy HMI oraz sygnatury bloków F (wyłącznie do wykrywania zmian).
Czy narzędzie modyfikuje bloki bezpieczeństwa?
Nie. Bloki F pozostają nietykalne, a ich sygnatury są zapisywane tylko po to, by wykrywać zmiany. Narzędzie nie importuje programu safety, żeby nie unieważnić sygnatury F i nie wymuszać ponownego odbioru bezpieczeństwa.
Od jakiej wersji TIA Portal to działa?
Testy prowadziłem na TIA Portal V21, w którym również bloki graficzne można wyeksportować do czytelnego tekstu. Starszych wersji na razie nie sprawdzałem.
Podsumowanie
Projekt TIA Portal może mieć czytelną historię zmian, nawet jeśli jego podstawowy format pozostaje binarny. W moim podejściu Git nie przechowuje samej binarki jako głównego źródła różnic, lecz stabilną reprezentację tekstową utworzoną przez TIA Openness.
Najważniejszym warunkiem jest powtarzalność: dwa eksporty projektu, w którym niczego nie zmieniono, muszą być identyczne. Dopiero wtedy historia pokazuje rzeczywiste modyfikacje zamiast dat eksportu i innych technicznych szczegółów.
Najbardziej użyteczny okazał się czytelny opis zmian sprzętowych. Zamiast informacji, że zmienił się plik, można zobaczyć, który adres IP został ustawiony albo jaki moduł pojawił się w stacji. Dzięki temu repozytorium staje się nie tylko archiwum programu, ale również praktyczną dokumentacją zmian w maszynie.
Jeśli chcesz nauczyć się programować sterowniki PLC od podstaw i wykorzystać takie podejście w realnych projektach, sprawdź nasz kurs programowania PLC w języku LAD/FBD. Zobacz też, jak wykorzystujemy nowoczesne narzędzia w automatyce we wpisie o komunikacji Pythona z PLC oraz o generowaniu projektów PLC w CODESYS z lokalnym agentem AI. Szczegóły interfejsu znajdziesz w dokumentacji Siemens TIA Openness.
O autorze
