Licencjonowanie oprogramowania w projektach modernizacji linii produkcyjnych

Kontekst modernizacji linii produkcyjnych a licencjonowanie oprogramowania

Modernizacja linii produkcyjnej zwykle zaczyna się od rozmowy o maszynach, czujnikach, nowych sterownikach czy integracji z systemami MES. Bardzo szybko okazuje się jednak, że to oprogramowanie i jego licencjonowanie potrafi zatrzymać projekt albo dramatycznie podnieść jego koszt. Wymiana szafy sterowniczej, nowy panel HMI czy przejście na nowy system SCADA to nie tylko kwestia techniczna – to zmiana środowiska, w którym obowiązują konkretne umowy licencyjne i prawa autorskie.

Zadaj sobie pytanie: chcesz tylko „odświeżyć automatykę”, czy równolegle przebudowujesz też warstwę IT i raportowania? Zakres modernizacji decyduje o tym, jak głęboko musisz wejść w temat licencji oprogramowania. Im więcej poziomów systemu dotykasz, tym więcej licencji pojawia się na horyzoncie – i tym łatwiej o konflikt interesów między producentem sprzętu, integratorem a Twoją firmą jako użytkownikiem końcowym.

Warstwy oprogramowania w typowej zmodernizowanej linii

Linia produkcyjna po modernizacji rzadko kończy się na jednym sterowniku PLC. Coraz częściej powstaje wielowarstwowy system obejmujący:

• PLC (sterowniki programowalne) – logika sterowania, komunikacja z IO, napędami, innymi PLC.
• HMI (panele operatorskie) – wizualizacja lokalna, zmiana parametrów, podgląd alarmów.
• SCADA – nadzór, archiwizacja, raporty, często integracja wielu linii.
• MES / systemy OEE – planowanie, śledzenie produkcji, analizy wydajności.
• Systemy raportowe i middleware – integracja z ERP, hurtownie danych, brokerzy komunikacyjni.
• Bazy danych – SQL, czasem NoSQL, często z osobnym licencjonowaniem serwera.

Każda z tych warstw to inne oprogramowanie, inny dostawca, inne warunki licencyjne. Do tego dochodzą narzędzia inżynierskie do programowania PLC/SCADA, które też są licencjonowane (zwykle jako development tools) oraz firmware w urządzeniach, które bywają powiązane z określonymi wersjami licencji.

Typowe źródła sporów licencyjnych w projektach modernizacyjnych

Modernizacja linii jest momentem, kiedy ujawnia się wiele starych zaniedbań. Kilka konfliktowych pytań pojawia się prawie zawsze:

• Kto ma prawa do kodu PLC i projektu SCADA – integrator czy zakład?
• Kto kupuje i „posiada” licencje: integrator w swoim imieniu, a potem refakturuje, czy klient bezpośrednio od producenta?
• Kto ma prawo rozwijać system po odejściu integratora? Czy nowy integrator może legalnie używać dotychczasowych projektów i bibliotek?
• Co z istniejącymi licencjami? Czy można je przenieść na nowe serwery, panele, sterowniki?
• Jak rozliczać licencje narzędzi inżynierskich? Czy integrator może korzystać z własnych licencji, a kod pozostaje w pełni do użytku klienta?

Jeżeli projekt modernizacyjny startuje bez odpowiedzi na te pytania, ryzykujesz niespodziewane dopłaty, spory po zakończeniu projektu, a w skrajnym przypadku nawet brak prawa do legalnego uruchomienia zmodernizowanej linii.

Krótki przykład: od jednego sterownika do zintegrowanego systemu

Wyobraź sobie zakład, w którym dotychczas linia była sterowana przez pojedynczy sterownik PLC i prosty panel. Integrator przy modernizacji proponuje:

• nowy sterownik PLC z większą pamięcią,
• nowy panel HMI,
• system SCADA centralny dla kilku linii,
• modułowy system raportowania OEE,
• integrację z bazą danych i ERP.

Technicznie brzmi sensownie. Ale od strony licencji rodzi pytania:

• Czy licencja SCADA jest na konkretny serwer, na liczbę sygnałów (tagów), czy na liczbę klientów?
• Kto będzie właścicielem licencji SCADA – integrator czy zakład?
• Czy licencja OEE to subskrypcja czy zakup wieczysty?
• Czy baza danych wymaga osobnej licencji serwerowej i CAL (Client Access Licenses)?
• Komu przysługują prawa do przygotowanych ekranów HMI, bibliotek funkcji PLC, skryptów raportowych?

Jeżeli na etapie oferty nie zdefiniujesz tych kwestii, modernizacja może skończyć się tak, że formalnie nie masz prawa rozwijać systemu ani nawet przenosić go na nowy serwer bez zgody (i opłaty) u konkretnego dostawcy.

Diagnoza na start: jaki masz zakres modernizacji?

Zanim wejdziesz głębiej w temat licencji, odpowiedz na kilka pytań dla siebie i swojego zespołu:

• Czy dotykasz tylko lokalnej automatyki (PLC/HMI), czy także warstwy SCADA/MES i integracji z ERP?
• Czy będą nowe serwery (fizyczne lub wirtualne), nowe stacje inżynierskie, nowe bazy danych?
• Czy planujesz scalenie kilku linii w jeden system nadrzędny?
• Czy modernizacja obejmuje też zmianę dostawcy technologii (np. migracja z jednego producenta PLC/SCADA na innego)?

Im więcej odpowiedzi „tak”, tym większe znaczenie ma świadome ułożenie licencjonowania oprogramowania. Bez tego projekt technicznie się uda, ale biznesowo może okazać się trudny do utrzymania i rozwoju.

Podstawy prawne i pojęcia, bez których rozmowa o licencjach nie ma sensu

Modernizacja linii produkcyjnej to nie jest czyste ćwiczenie inżynierskie. To także obszar, w którym bardzo konkretnie działa prawo autorskie. Jeżeli nie odróżniasz licencji od przeniesienia praw autorskich i nie wiesz, kiedy projekt PLC jest „utworem”, a kiedy „konfiguracją”, bardzo łatwo oddać więcej kontroli, niż zamierzałeś.

Program jako utwór: co w automatyce podlega ochronie

W polskim prawie – i szerzej w europejskim systemie prawnym – program komputerowy jest utworem chronionym prawem autorskim. To dotyczy nie tylko aplikacji biurowych, ale również:

• programów PLC (drabinka, FBD, SCL, ST itd.),
• projektów SCADA (ekrany, skrypty, logika alarmowa),
• aplikacji HMI,
• makr i skryptów (np. do generowania raportów),
• autorskich bibliotek funkcji, bloków funkcyjnych, sterowników komunikacyjnych.

Co jest „utworem”, a co tylko „konfiguracją”? Granica bywa płynna, ale w praktyce:

• Utwór – indywidualne, twórcze rozwiązanie: np. rozbudowana biblioteka sterowania recepturami, zaawansowany system raportów, autorski moduł diagnostyki.
• Konfiguracja – proste ustawienia, które wynikają z instrukcji obsługi i nie noszą cech oryginalności: podstawowe parametry napędu, proste mapowanie sygnałów IO.

Po co ta różnica? Bo dla utworów kluczowe są prawa autorskie (majątkowe i osobiste), które decydują, kto może program modyfikować, kopiować, rozwijać. Konfigurację częściej traktuje się jako element wdrożenia, ale i tu mogą obowiązywać warunki licencji narzędzia (np. systemu SCADA).

Licencja a przeniesienie autorskich praw majątkowych

Przy projektach przemysłowych masz zasadniczo dwa modele prawne:

• Licencja – autor (np. integrator) pozostaje właścicielem praw autorskich, a użytkownik (zakład) dostaje prawo korzystania w określonym zakresie (pola eksploatacji).
• Przeniesienie autorskich praw majątkowych – prawa przechodzą na klienta. Integrator traci możliwość swobodnego zarządzania utworem (poza prawami osobistymi, których przenieść nie można).

Jak to przekłada się na modernizację?

• Jeżeli masz tylko licencję na program PLC/SCADA, integrator często zachowuje kontrolę nad dalszym rozwojem – np. nowy integrator nie może legalnie użyć tych samych bibliotek bez zgody autora.
• Jeżeli prawa zostały przeniesione na Twoją firmę, możesz swobodniej zmieniać dostawcę usług inżynierskich, a kod staje się Twoim zasobem.

W praktyce rzadko spotyka się pełne przeniesienie praw do wszystkiego, co stworzył integrator. Często stosuje się model mieszany: zakład nabywa prawa do części specyficznej dla swojej linii (logika procesu), a integrator zachowuje prawa do swoich uniwersalnych bibliotek (których używa w innych projektach).

Rodzaje licencji i pola eksploatacji w projektach przemysłowych

Od strony prawa autorskiego licencje dzieli się m.in. na:

• Wyłączne – tylko licencjobiorca może korzystać z utworu na określonych polach eksploatacji, autor nie może udzielić podobnej licencji innym podmiotom w tym zakresie.
• Niewyłączne – autor może udzielić podobnych uprawnień wielu podmiotom.
• Sublicencja – dalsze udzielenie licencji przez licencjobiorcę, jeśli umowa mu na to pozwala (ważne np. przy integratorach, którzy udostępniają klientowi oprogramowanie producenta).

Pola eksploatacji określają, co dokładnie możesz robić z oprogramowaniem. W automatyce typowe pola to:

• utrwalanie i zwielokrotnianie programu (instalacja na określonych urządzeniach),
• modyfikacja i tworzenie wersji pochodnych (np. rozwój projektu PLC),
• udostępnianie dalszym integratorom (outsourcing serwisu),
• używanie w konkretnym zakładzie / lokalizacji / liczbie linii.

Jeżeli w umowie z integratorem czy producentem nie opiszesz tych pól jasno, w razie sporu decyzję, co wolno, podejmie interpretacja sądu lub dostawcy – zwykle mniej korzystna dla Ciebie.

Specyfika licencjonowania w środowisku przemysłowym

Producenci PLC, SCADA czy MES nie operują językiem „wyłączna/niewyłączna” w ulotkach marketingowych. Ich licencje są budowane wokół modeli technicznych:

• Runtime vs development – licencja na uruchamianie (runtime) programu na maszynie vs licencja na tworzenie/edytowanie (development) projektu.
• Na urządzenie – np. licencja przypisana do konkretnego panelu HMI lub sterownika.
• Na instancję / serwer – licencja powiązana z konkretną instalacją serwera SCADA.
• Na użytkownika / stanowisko – dla narzędzi inżynierskich: licencje jednostanowiskowe lub sieciowe (pływające).
• Per CPU, per tag, per client – ograniczenia liczby procesorów, sygnałów, klientów HMI.

To wszystko przekłada się potem na język prawa: np. ograniczenie instalacji do jednego serwera to ograniczenie pola eksploatacji do konkretnego nośnika i lokalizacji. Z kolei licencja pływająca na narzędzie inżynierskie to zgoda na zwielokrotnianie w określonym zakresie (do liczby równoczesnych użytkowników).

Kontrolne pytanie: masz dokumentację licencyjną?

Zanim zaczniesz negocjować nowe licencje przy modernizacji, odpowiedz szczerze: do których programów w zakładzie masz faktycznie umowy/licencje i faktury? Typowa sytuacja:

• oprogramowanie SCADA „zainstalował kiedyś integrator” – nikt nie wie, na kogo jest licencja,
• narzędzia inżynierskie są na komputerach utrzymania ruchu, ale klucze licencyjne należą do poprzedniego dostawcy,
• bazy danych i systemy raportowe działają na serwerze IT, ale licencje kupiono w innym projekcie, niekoniecznie na ten sposób użytkowania.

Bez uporządkowania tego obszaru modernizacja stanie się mieszanką legalnego i „nieformalnego” użycia softu. Audyt producenta w takim momencie bywa wyjątkowo bolesny. Zacznij więc od przeglądu tego, co już masz – nawet, jeśli początkowo okaże się to nieuporządkowane.

Mapa oprogramowania w projekcie modernizacji – co trzeba zidentyfikować

Nie da się dobrze zaplanować licencjonowania bez rzetelnej inwentaryzacji. W modernizacji linii produkcyjnej trzeba spojrzeć dalej niż na „to, co widać na ekranie”. Wiele licencji ukrywa się pod firmware, bibliotekami czy na poziomie serwerów, o których automatyk na co dzień nawet nie myśli.

Jak zrobić inwentaryzację oprogramowania przed modernizacją

Przygotuj prostą, ale konsekwentnie prowadzoną listę. Można ją oprzeć na arkuszu kalkulacyjnym albo systemie CMDB, jeśli taki posiadasz. Kluczowe kroki:

• Lista urządzeń automatyki – wszystkie sterowniki PLC, panele HMI, komputery przemysłowe, serwery SCADA/MES, konwertery, bramy komunikacyjne.

Jakie kategorie oprogramowania trzeba uwzględnić

Jeżeli chcesz mieć kontrolę nad licencjami, potrzebujesz przejrzystej mapy. Zadaj sobie pytanie: co w Twojej linii „myśli”, „zbiera dane” i „pokazuje operatorowi świat”? Z reguły wychodzą z tego cztery obszary:

• Warstwa sterowania – firmware PLC, serwonapędów, robotów; projekty PLC; biblioteki producentów.
• Warstwa wizualizacji i nadzoru – SCADA, HMI, panele operatorskie, aplikacje webowe dla brygadzistów.
• Warstwa integracji i danych – MES, systemy raportowe, middleware, bramy OPC UA, oprogramowanie do integracji z ERP.
• Warstwa inżynierska – narzędzia programistyczne (TIA Portal, Studio 5000, EPLAN, narzędzia do konfiguracji napędów i sieci).

Przy każdym elemencie zadaj trzy pytania kontrolne:

• Na czyim sprzęcie to działa (czyj serwer, czyj panel, czyj sterownik)?
• Na kogo jest wystawiona licencja (firma, integrator, centrala, lokalny zakład)?
• Kto ma dziś praktyczną możliwość modyfikacji (dostęp do narzędzi, haseł, kluczy licencyjnych)?

Jeżeli choć raz odpowiedź brzmi „nie wiem”, masz obszar ryzyka przy modernizacji.

Ukryte licencje: firmware, biblioteki, dodatki

Część licencji „nie rzuca się w oczy”, bo nie masz osobnej faktury. Przykłady?

• Firmware napędów i robotów – aktualizacja może wymagać aktywnej umowy serwisowej lub zakupionej opcji.
• Biblioteki producenta – gotowe bloki do obsługi serwonapędów, PID, motion; czasem są darmowe, czasem płatne lub ograniczone do konkretnej serii sterowników.
• Moduły dodatków (add-ons) – np. moduły raportowe do SCADA, gotowe pulpity energetyczne, pluginy do OPC.

Zastanów się, czy przy modernizacji planujesz:

• aktualizację firmware do nowej wersji,
• przeniesienie projektu na nowy typ sterownika,
• podmianę napędów lub modułów komunikacyjnych.

Jeżeli tak – sprawdź, czy dotychczasowe licencje obejmują takie zmiany, czy trzeba je będzie uzupełnić. Zdarza się, że „tani” retrofit kończy się dodatkowymi kosztami licencji firmware, o których nikt nie wspomniał na etapie oferty.

Oprogramowanie „brzegowe” – między IT a automatyką

Modernizacja coraz częściej dotyka systemów, które formalnie należą do IT, ale funkcjonalnie są krytyczne dla produkcji. Jakie to systemy?

• serwery baz danych (SQL, Oracle, PostgreSQL w wersjach komercyjnych),
• serwery wirtualizacji (VMware, Hyper-V) z licencjami per host lub per VM,
• systemy backupu, które obejmują serwery SCADA/MES,
• narzędzia analityczne i BI integrujące dane produkcyjne.

Przygotowując modernizację, zapytaj dział IT:

• Na jakich licencjach działa obecnie baza danych i czy wolno ją użyć do nowych systemów?
• Czy licencje wirtualizacji obejmują nowe maszyny wirtualne pod SCADA/MES?
• Kto jest formalnym właścicielem licencji – lokalny zakład czy centrala?

Brak porozumienia na linii automatyka–IT kończy się czasem zakupem drugiego, zbędnego serwera SQL, bo nikt nie sprawdził, że istniejąca umowa ma jeszcze wolne „sloty”.

Dokumenty, które powinieneś mieć przed startem projektu

Nie chodzi o to, aby gromadzić segregatory papieru. Raczej o kilka kluczowych dowodów, że masz prawo korzystać z tego, co chcesz modernizować.

• Faktury i potwierdzenia zakupu licencji – z numerami licencji lub referencjami do systemów producenta.
• Umowy licencyjne / serwisowe – szczególnie te, które określają prawo do aktualizacji i migracji.
• Umowy z integratorami – z zapisami o prawach autorskich do projektów PLC/SCADA.
• Rejestry licencji – pliki, klucze sprzętowe, konta w portalach producentów.

Zadaj sobie proste pytanie: gdyby jutro zmienił się kierownik utrzymania ruchu i szef IT, czy ktoś w firmie byłby w stanie udowodnić, że wszystkie krytyczne systemy mają ważne licencje? Jeśli odpowiedź jest niepewna, włącz uporządkowanie dokumentów do zakresu projektu modernizacji.

Modele licencjonowania w automatyce i systemach produkcyjnych

Producenci automatyki industrialnej rzadko mówią językiem „standardowych” licencji znanych z biurowych systemów IT. Ich modele są podporządkowane realiom produkcji: liczbie linii, tagów, sterowników, użytkowników. Jakie modele faktycznie spotykasz na hali?

Licencje przypisane do sprzętu

To najczęstszy model w klasycznej automatyce. Licencja jest „przyspawana” do konkretnego urządzenia:

• panel HMI z licencją runtime na wbudowaną wizualizację,
• sterownik PLC z aktywowaną opcją komunikacyjną lub motion,
• moduł gateway z wgranym pakietem protokołów.

Co to oznacza przy modernizacji?

• wymiana urządzenia na nowsze wymaga przeniesienia lub zakupu nowej licencji,
• „kanibalizacja” starych paneli na części może prowadzić do utraty prawa do wykorzystania starej licencji,
• przebudowa aplikacji HMI na innym panelu może naruszać warunki licencji, jeśli była ona ograniczona do konkretnego modelu.

Zanim wpiszesz w projekt „wymiana wszystkich paneli HMI na nową serię”, sprawdź, czy budżetuje się wyłącznie hardware, czy również nowe runtime’y.

Licencje runtime – per serwer, per instancja, per tag

Systemy SCADA i MES najczęściej rozliczane są w modelu runtime:

• per serwer / instancja – każda instalacja serwera to osobna licencja,
• per tag / punkt danych – limit liczby zmiennych procesowych,
• per klient / sesję – liczba równoczesnych połączeń operatorów,
• per funkcja – osobno logowanie danych historycznych, raportowanie, web-clienty itd.

Jakie pytania zadać sobie przy modernizacji SCADA?

• Czy liczba tagów po rozbudowie linii nie przekroczy limitów licencyjnych?
• Czy migracja na nową wersję wymaga osobnej opłaty, czy jest w ramach aktualnego maintenance?
• Czy planowana konsolidacja kilku serwerów SCADA w jeden duży jest zgodna z obecnymi licencjami?

Bywa, że modernizacja zmniejszająca liczbę sterowników, ale zwiększająca liczbę sygnałów (np. dodatkowe pomiary) „zjada” tagi i wymusza upgrade licencji SCADA. Jeżeli tego nie przewidzisz, ostatni etap uruchomienia zaskoczy dodatkowymi kosztami.

Licencje narzędzi inżynierskich – per stanowisko, per użytkownik, pływające

Narzędzia inżynierskie (IDE do PLC, konfiguratory sieci, narzędzia do napędów) działają inaczej niż runtime. Tu wchodzą w grę modele:

• standalone (node-locked) – licencja przypisana do konkretnego komputera,
• pływająca (floating) – licencja na serwerze, z której korzysta określona liczba użytkowników jednocześnie,
• per user – logowanie do konta w chmurze producenta uprawnia do użycia narzędzia na kilku urządzeniach.

Jak to się ma do modernizacji?

• Jeżeli tworzysz projekt w wielu lokalizacjach (centrala + zakład), lepiej sprawdza się model pływający niż zestaw stanowisk lokalnych.
• Jeżeli utrzymanie ruchu ma samodzielnie modyfikować programy, potrzebujesz dla nich legalnego dostępu do narzędzia, nie tylko jednego klucza u integratora.
• Jeżeli wymieniasz komputery inżynierskie, upewnij się, że licencje można przenieść (deaktywacja/aktywacja), a nie są „spalone” na starym sprzęcie.

Zapytaj siebie: kto w Twojej organizacji faktycznie programuje sterowniki i HMI – ja, mój integrator, czy mieszany zespół? Od tej odpowiedzi zależy, czy budować własną pulę licencji inżynierskich, czy oprzeć się na zasobach dostawcy.

Subskrypcja, maintenance, jednorazowy zakup – co wybrać

Coraz więcej producentów automatyki przechodzi z modelu „kup raz na zawsze” na subskrypcje lub płatne umowy utrzymaniowe (maintenance). Każdy z modeli ma plusy i minusy:

• Licencja wieczysta + opcjonalny maintenance
  Kupujesz licencję raz, a płacisz roczny maintenance za nowe wersje i wsparcie. Dobre, jeśli linia ma działać 10+ lat, a aktualizacje robisz rzadko. Ryzyko: po latach brak maintenance utrudnia migrację na nową wersję.
• Subskrypcja (SaaS, licencje czasowe)
  Płacisz co rok lub co miesiąc. Niższy próg wejścia, ale system przestaje być legalny po zakończeniu płatności. Dobre przy projektach pilotażowych, mniej komfortowe dla krytycznych linii.
• Hybrid
  Część funkcji w licencji wieczystej (podstawowy runtime), dodatki w subskrypcji (np. web klient, analityka).

Przy modernizacji zadaj sobie pytanie: jak długo planujesz eksploatować daną generację systemu? Na 3 lata pilotażu MES wybór subskrypcji jest sensowny. Na 15-letni cykl życia SCADA – bardziej opłaca się licencja wieczysta z rozsądnie planowanym maintenance.

Licencjonowanie w środowiskach zwirtualizowanych i chmurowych

Jeżeli część systemów przenosisz na wirtualizację lub do chmury, scenariusz licencji się komplikuje. Pojawiają się pytania:

• czy licencja „per maszyna fizyczna” wciąż obowiązuje, gdy serwer SCADA działa na VM, a fizyczny host się zmienia,
• czy chmurowy backup lub DR (disaster recovery) wymaga osobnych licencji „standby”,
• czy możesz replikować serwer SCADA/MES na środowisko testowe bez płatnej licencji produkcyjnej.

U niektórych producentów licencja jest wiązana z identyfikatorem sprzętowym, u innych – z kluczem softwarowym, który można przenosić. Przed migracją na wirtualizację zapytaj dostawcę wprost:

• czy potrzebne są dodatkowe licencje na środowiska test/QA,
• jak działa licencja w scenariuszu awaryjnego przełączenia na drugi serwer,
• jak rozliczane są serwery w chmurze (np. instancje w Azure/AWS).

Bez tego możesz stworzyć wzorowo zwirtualizowaną infrastrukturę, która jednak nie spełnia warunków licencyjnych producenta.

Relacje między producentem sprzętu, integratorem a użytkownikiem końcowym

Modernizacja linii to nie tylko skrzynki i kable, ale również układ sił między trzema stronami: producentem, integratorem i zakładem. Każda z nich ma własne interesy licencyjne. Jak je pogodzić, tak aby nie zostać zakładnikiem jednego dostawcy?

Kto faktycznie jest licencjobiorcą?

Podczas audytów często wychodzi na jaw, że formalnym licencjobiorcą wielu kluczowych systemów nie jest zakład, ale integrator. Typowy scenariusz:

• integrator kupuje licencję SCADA „na siebie”,
• instaluje ją w zakładzie klienta,
• po kilku latach rozstajecie się, a Ty nie masz ani dostępu do konta licencyjnego, ani prawa do aktualizacji.

Zadaj integratorowi jasne pytania:

• Na kogo będą zarejestrowane licencje – na Twoją firmę czy na jego?
• Czy dostaniesz pełny dostęp do konta klienta w portalu producenta (myAccount, License Portal itd.)?
• Jak zostanie udokumentowane prawo do aktualizacji / migracji na nowszą wersję?

Jeżeli to Ty jesteś integratorem, zastanów się, jaki masz model biznesowy: chcesz świadomie być „bramą” do licencji dla klienta, czy budować współpracę na przejrzystości i oddawaniu licencji na klienta końcowego?

Własność kodu integratora vs prawa zakładu

Większość integratorów posiada swoje biblioteki, szablony i gotowe moduły. Z ich punktu widzenia to know-how, którego nie chcą oddać w całości. Z punktu widzenia zakładu bywa to „czarna skrzynka”, która utrudnia zmianę dostawcy. Jak z tego wybrnąć?

Jak opisać w umowie prawa do kodu i konfiguracji

Zanim zapytasz integratora o „oddanie kodu źródłowego”, doprecyzuj, co masz na myśli. W projektach modernizacji przeplatają się co najmniej trzy kategorie:

• kod standardowy integratora – biblioteki bloków funkcyjnych, szablony ekranów, frameworki raportowe,
• kod specyficzny dla Twojej linii – logika sekwencji, receptury, interfejsy z Twoim ERP/MES,
• konfiguracje i dane technologiczne – parametry napędów, nastawy PID, modele produktów.

Jak to przełożyć na zapisy umowy?

• Licencja na używanie standardu integratora – integrator zachowuje prawa autorskie do swoich bibliotek, ale udziela zakładowi bezterminowej licencji na korzystanie w ramach danej instalacji. Możesz eksploatować i modyfikować, choć nie sprzedasz tego dalej jako własnego produktu.
• Przeniesienie praw do kodu dedykowanego – wszystko, co powstaje „pod Ciebie” (algorytmy, interfejsy, raporty), jest przenoszone na Ciebie jako na zamawiającego. Integrator może uzyskać prawo do wykorzystania ogólnych rozwiązań w innych projektach, ale bez wrażliwych danych.
• Pełna przejrzystość konfiguracji – wymóg przekazania plików projektowych PLC/HMI/SCADA w formie edytowalnej, wraz z hasłami lub procedurą ich przekazania.

Zadaj sobie pytanie: czy chcesz mieć pełną możliwość zmiany dostawcy za 3 lata? Jeśli tak, domagaj się wprost w umowie: prawa do modyfikacji i przekazywania kodu nowemu integratorowi, a nie tylko „wglądu” do projektu.

Hasła, blokady i „uzależnianie” od integratora

Częsty problem wychodzi dopiero przy pierwszej większej awarii po modernizacji. Okazuje się, że:

• programy PLC są zabezpieczone hasłem, którego nikt w zakładzie nie zna,
• panele HMI mają zablokowany dostęp do trybu serwisowego,
• projekty SCADA są zaszyfrowane i otwierają się tylko u integratora.

Nie chodzi o to, by każdy operator mógł „grzebać” w kodzie. Chodzi o to, by zakład jako właściciel instalacji miał kontrolę nad dostępem. Jak to ułożyć?

• Ustal i zapisz w umowie, że hasła administracyjne i serwisowe są własnością zakładu, a integrator przekazuje je upoważnionej osobie (np. kierownik UR).
• Wprowadź procedurę zmiany haseł – kto może, w jakich sytuacjach, jak jest to dokumentowane.
• Rozważ depozyt haseł – np. w zaufanym repozytorium IT lub u notariusza/organizacji trzeciej, jeśli integrator boi się nieuprawnionego dostępu.

Zastanów się: czy dziś, bez telefonu do integratora, jesteś w stanie wgrać poprawkę do programu PLC? Jeżeli odpowiedź brzmi „nie”, linia jest zależna nie tylko technologicznie, ale i licencyjnie.

Dostęp do kont producentów i portali licencyjnych

Coraz więcej licencji zarządza się w portalach online: konta klientów, rejestracja instalacji, przypisywanie licencji do numerów seryjnych. Tutaj łatwo o subtelne „zawłaszczenie” relacji przez integratora.

Prosty scenariusz: integrator zakłada konto u producenta na swój adres e-mail, dodaje tam Twoją fabrykę jako „site” i przypisuje wszystkie licencje do swojej firmy. Póki współpraca jest dobra – nie ma problemu. Problem pojawia się, gdy chcesz:

• zmienić integratora,
• samodzielnie przedłużyć maintenance,
• ściągnąć aktualizację krytyczną z portalu producenta.

Jak to uporządkować?

• Ustal, że konto główne u producenta zakłada zakład (na firmową skrzynkę ogólną), a integrator jest dodawany jako partner/administrator techniczny.
• W umowie wpisz, że wszystkie licencje przypisuje się do konta zakładu, a integrator nie ma prawa ich „przerejestrowywać” na siebie bez zgody.
• Poproś integratora o listę wszystkich zakupionych licencji z numerami seryjnymi oraz informacją, na jakie konto zostały przypisane.

Zadaj sobie pytanie: kto dziś może zalogować się do portalu głównych producentów systemów używanych na Twojej linii? Jeżeli tylko integrator – zmień to przy najbliższej modernizacji.

Podwykonawcy integratora a poufność i licencje

Przy większych modernizacjach integrator korzysta z podwykonawców: freelancerów, firm od napędów, specjalistów od SCADA/MES. W tle pojawiają się kolejne licencje, konta i prawa autorskie.

Co to może oznaczać dla Ciebie?

• Część kodu napisał podwykonawca, który nie zrzekł się praw autorskich, więc przy konflikcie może blokować jego użycie w kolejnych modernizacjach.
• Licencje narzędzi inżynierskich są na firmę podwykonawcy, który przechowuje master-projekty, podczas gdy Ty dostajesz tylko skompilowaną wersję.
• Brak jasnego NDA i zasad dostępu powoduje, że dane procesowe wędrują szerzej, niż zakładałeś.

Jak podejść do tematu?

• Zażądaj, by w umowie z integratorem było jasno zapisane, że podwykonawcy przenoszą prawa do stworzonego kodu na integratora, a ten – na Ciebie w zakresie instalacji u Ciebie.
• Wprowadź zapis, że żaden podwykonawca nie może być formalnym licencjobiorcą kluczowych systemów używanych w Twojej fabryce.
• Poproś o listę podwykonawców pracujących przy projekcie wraz z zakresem odpowiedzialności – nie z ciekawości, tylko by mieć ścieżkę komunikacji przy przyszłych modernizacjach.

Zastanów się: czy wiesz, kto poza integratorem miał dostęp do Twoich projektów PLC/SCADA przy ostatniej modernizacji? Jeżeli nie, następny kontrakt przygotuj z większą świadomością.

Rozdzielenie usług integracji od dostaw licencji

Możesz kupić system „pod klucz” – integrator dostarcza sprzęt, oprogramowanie, licencje i usługę. Możesz też rozdzielić role: zakład kupuje licencje bezpośrednio od producenta lub dystrybutora, a integrator świadczy usługę konfiguracji. Każdy model ma swoje skutki dla licencjonowania.

Jeśli integrator jest pośrednikiem licencji, zyskujesz:

• jeden punkt kontaktu i rozliczeń,
• często lepszą cenę pakietową (sprzęt + licencje + usługa),
• mniejszą „papierologię” po swojej stronie.

Ale płacisz za to:

• mniejszą przejrzystością, jakie licencje faktycznie kupiłeś,
• większą zależnością od integratora w przyszłych modernizacjach,
• czasem gorszą pozycją negocjacyjną wobec producenta (bo formalnie nie jesteś klientem końcowym).

Jeżeli rozdzielisz role i to Ty kupujesz licencje, integrator:

• konfiguruje i przekazuje Ci system działający na licencjach należących do zakładu,
• ma mniejszą możliwość „przytrzymania” Cię na licencjach w razie konfliktu,
• może skupić się na roboczogodzinach i jakości integracji, a nie na marży ze sprzedaży licencji.

Zadaj sobie pytanie: co jest Twoim głównym celem – minimalna cena w tym projekcie czy większa niezależność w kolejnych modernizacjach? Od odpowiedzi zależy, czy pójdziesz w pełne „pod klucz”, czy w model z oddzielnym zakupem licencji.

Umowy serwisowe a prawa licencyjne

Po modernizacji przychodzi etap utrzymania. Często podpisujesz umowę serwisową: z integratorem, producentem lub jednym i drugim. W tle są licencje – czasem oczywiste, czasem ukryte.

Na co zwrócić uwagę?

• Kto ma prawo do zdalnego dostępu – integrator, producent, obie strony? Czy dostęp jest licencjonowany (np. dodatkowe moduły remote support)?
• Aktualizacje a licencje runtime – czy w cenie serwisu przewidziano upgrade’y wersji SCADA/MES/PLC, czy tylko „pomoc na telefon” bez zmian wersji?
• Środowisko testowe – czy w ramach serwisu integrator utrzymuje testowy klon systemu? Jeżeli tak, jak są licencjonowane te instancje (pełne, testowe, demo)?

Dobrym krokiem jest zapisanie w umowie serwisowej, że:

• wszelkie zmiany w konfiguracji licencji (dołożenie modułów, migracja na inne serwery) są dokumentowane i przekazywane zakładowi w formie aktualnej listy licencji,
• integrator w razie zakończenia umowy nie usuwa ani nie dezaktywuje licencji zakupionych dla zakładu,
• zdalny dostęp jest ściśle powiązany z polityką bezpieczeństwa IT/OT i nie wymusza nieakceptowalnych zmian w licencjonowaniu (np. otwarcia serwera na cały Internet).

Pytanie pomocnicze: czy Twoja aktualna umowa serwisowa opisuje, co stanie się z licencjami w razie zakończenia współpracy? Jeżeli nie – nowa modernizacja to dobry moment, by to uporządkować.

Zmiana integratora a ciągłość licencji

Prędzej czy później pojawia się scenariusz zmiany dostawcy. Może z powodów jakościowych, może kosztowych, a może z powodu przejęcia firmy integratorskiej przez konkurencję. W tle jest kluczowe pytanie: czy nowy integrator będzie mógł legalnie pracować na istniejących licencjach?

Tu pojawiają się kilka pułapek:

• Licencje narzędzi inżynierskich są tylko na firmę starego integratora – nowy nie ma czym otworzyć Twoich projektów bez zakupu nowych licencji.
• Licencje SCADA/MES są zarejestrowane na starego integratora – utrata maintenance uniemożliwia upgrade wymagany przez nową firmę.
• Producent systemu wymaga opłaty rejestracyjnej za „przepisanie” licencji na nową firmę.

Jak się przed tym zabezpieczyć już na etapie modernizacji?

• Zapisz w umowie, że licencje są zarejestrowane na zakład i że możesz udostępniać je zewnętrznym usługodawcom w celu utrzymania i rozwoju systemu.
• Ustal z producentem (najlepiej na piśmie), że zmiana integratora nie wymaga ponownego zakupu licencji, a jedynie ewentualnej aktualizacji kontaktów serwisowych.
• Poproś integratora o przekazanie pełnej dokumentacji licencyjnej po zakończeniu projektu: klucze, certyfikaty, loginy, procedury przenoszenia licencji.

Zadaj sobie pytanie: gdyby jutro trzeba było ogłosić przetarg na nowego integratora, czy masz komplet informacji licencyjnych, żeby mógł uczciwie wycenić pracę? Jeśli nie – zaplanuj uzupełnienie dokumentacji przy bieżącej modernizacji.

Transparentność finansowa licencji w projektach modernizacji

Licencje często lądują w budżecie jako jedna pozycja: „oprogramowanie”. To prostsze na etapie zakupów, ale potem utrudnia planowanie kolejnych kroków. Przejrzystość bardzo pomaga – zarówno Tobie, jak i integratorowi.

Jak ułożyć budżet licencyjny?

• Rozbij koszty na runtime, narzędzia inżynierskie, maintenance, subskrypcje. Wtedy widzisz, co jest kosztem inwestycyjnym, a co operacyjnym.
• Poproś integratora o odrębne pozycje dla licencji producenta i dla jego własnych komponentów (np. biblioteki, moduły raportowe, autorski middleware).
• Zaplanuj rezerwę budżetową na rozbudowę licencji – dodatkowe tagi, klientów, moduły komunikacyjne. Modernizacja rzadko kończy się dokładnie na tym, co zakładał pierwszy projekt.

Dobre pytanie do siebie: czy wiesz dziś, ile z kosztu projektu było „żelazem”, ile „roboczogodzinami”, a ile licencjami? Przy kolejnej modernizacji postaraj się tę strukturę zobaczyć wyraźnie – łatwiej wtedy negocjować i planować długoterminowo.

Najczęściej zadawane pytania (FAQ)

Jak ustalić, kto ma prawa do programu PLC i projektu SCADA po modernizacji linii?

Zacznij od pytania: co chcesz mieć „u siebie na własność” – całość kodu, czy tylko część związaną z Twoją technologią? Standardowo integrator domyślnie zachowuje prawa autorskie, a Ty dostajesz licencję na korzystanie z gotowego rozwiązania w swoim zakładzie.

Jeżeli zależy Ci na swobodzie zmiany integratora i dalszego rozwoju systemu, doprecyzuj w umowie:

• czy następuje przeniesienie autorskich praw majątkowych do kodu specyficznego dla Twojej linii,
• czy integrator może zachować prawa do swoich uniwersalnych bibliotek, ale musi dać Ci licencję na ich używanie w tym konkretnym obiekcie,
• w jakim formacie i zakresie otrzymujesz projekt (pliki źródłowe PLC/SCADA, hasła, dokumentację).

Zadaj sobie proste pytanie: czy w razie konfliktu z integratorem nowa firma będzie mogła legalnie wczytać i zmodyfikować istniejący projekt?

Czy przy modernizacji muszę kupować wszystkie licencje od nowa?

Nie zawsze. Najpierw sprawdź, jakie licencje już masz i na jakich warunkach. Czy są przypisane do:

• konkretnego sprzętu (np. numer seryjny panelu, sterownika, serwera),
• konkretnej wersji oprogramowania,
• liczby tagów/użytkowników/klientów sieciowych?

Następne pytanie: co się faktycznie zmienia – tylko sprzęt, czy też środowisko (system operacyjny, wersja SCADA, typ bazy danych)?

W wielu systemach możliwe jest:

• przeniesienie licencji na nowy serwer lub panel (czasem za opłatą serwisową),
• upgrade do nowszej wersji, jeśli utrzymywane było wsparcie techniczne (maintenance),
• konwersja licencji sprzętowej (np. klucz USB) na licencję softwarową lub odwrotnie.

Kluczowe jest, żeby na etapie oferty jasno ustalić z dostawcą: które licencje są nowe, które przenoszone, a które aktualizowane. Bez tego możesz nieświadomie zapłacić dwa razy za to samo.

Jak wybrać model licencjonowania SCADA/MES przy rozbudowie linii?

Najpierw odpowiedz sobie: co jest ważniejsze – elastyczność rozbudowy czy minimalny koszt wejścia? Popularne modele to:

• licencja na liczbę sygnałów (tagów) – dobra, gdy znasz skalę systemu i nie spodziewasz się gwałtownego wzrostu,
• licencja na liczbę klientów/stanowisk operatorskich – logiczna przy rozbudowanej wizualizacji, ale stabilnej liczbie sygnałów,
• licencja na serwer/instancję – bywa prostsza, ale droższa przy małych systemach,
• subskrypcja (np. roczna) – mniejszy koszt startu, ale stałe opłaty.

Zastanów się też, czy planujesz łączyć kilka linii w jeden system nadrzędny. Jeśli tak, unikaj zbyt „ciasnego” modelu (np. licencji na małą liczbę tagów), który przy każdej rozbudowie wymusi kosztowny upgrade.

Zapytaj dostawcę wprost:

• jak rozliczana jest rozbudowa (dorzucenie nowej linii, serwera, stanowiska),
• czy licencje da się przenieść między serwerami fizycznymi i wirtualnymi,
• jak wygląda polityka licencjonowania w architekturze redundantnej (primary/backup).

Dobór modelu licencjonowania warto zrobić razem z kimś, kto zna Twoją strategię rozwoju na 3–5 lat, a nie tylko bieżący projekt.

Czy nowy integrator może legalnie używać istniejącego projektu PLC/SCADA?

To zależy od tego, co masz zapisane w umowach. Zadaj sobie trzy pytania:

• czy masz przeniesione autorskie prawa majątkowe do kodu, czy tylko licencję na korzystanie,
• czy licencja dopuszcza modyfikacje przez osoby trzecie,
• czy masz dostęp do pełnych plików źródłowych i haseł.

Jeżeli dysponujesz pełnią praw (lub szeroką licencją) oraz źródłami, nowy integrator zwykle może legalnie:

• wczytać projekt,
• zmodyfikować go na Twoje zlecenie,
• utrzymywać system bez udziału pierwotnego wykonawcy.

Problemy pojawiają się, gdy:

• integrator zastrzegł brak zgody na modyfikacje przez inne podmioty,
• nie przeniesiono praw, a licencja jest bardzo wąska,
• nie masz haseł ani plików źródłowych, tylko skompilowany kod w sterowniku.

Jeśli dopiero planujesz modernizację, wpisz w umowę wprost: „zamawiający ma prawo zlecać rozwój i modyfikacje systemu osobom trzecim” i określ, które elementy kodu podlegają temu zapisowi.

Jak potraktować autorskie biblioteki integratora użyte w mojej linii produkcyjnej?

Najpierw rozróżnij: co jest „generyjne”, a co „Twoje”. Biblioteki integratora (np. standardowe bloki sterowania napędami, typowe moduły alarmowania) są zwykle jego narzędziem pracy w wielu projektach. Logika konkretnego procesu w Twoim zakładzie – to część specyficzna.

Praktyczne rozwiązanie to model mieszany:

• integrator zachowuje prawa autorskie do swoich bibliotek,
• Ty dostajesz niewyłączną licencję na używanie tych bibliotek w swoim zakładzie, w tej linii lub w określonej liczbie obiektów,
• do części specyficznej (algorytm procesu, receptury, specyficzne raporty) prawa są przenoszone na Ciebie.

Zadaj integratorowi proste pytania: „Które elementy kodu uważasz za swoje biblioteki, a które za część dedykowaną dla nas?” oraz „Jaką licencję dostajemy na biblioteki w kontekście przyszłych modyfikacji przez inne firmy?”. Bez tego możesz być związany jednym wykonawcą na lata.

Jak ułożyć kwestię licencji narzędzi inżynierskich (programowanie PLC/SCADA)?

Tu kluczowe jest rozdzielenie dwóch tematów: kto ma licencje na narzędzia inżynierskie, a kto ma prawa do stworzonego kodu. Integrator może programować na swoich licencjach TIA Portal, Studio 5000 czy narzędziach SCADA, a efekt pracy (program PLC, projekt SCADA) może być Twoim zasobem – o ile umowa tak stanowi.

Przemyśl:

• czy chcesz mieć własne licencje inżynierskie na utrzymanie ruchu (np. 1–2 stanowiska w zakładzie),
• czy wystarczy, że integrator będzie wykonywał wszystkie zmiany na swoich licencjach, a Ty skupisz się tylko na eksploatacji,
• czy dopuszczasz w przyszłości własne modyfikacje (np. drobne zmiany w alarmach czy ekranach HMI) przez swój dział automatyki.