Sterownik zaprogramuje dziś wielu. Różnica między instalacją, która pracuje spokojnie przez dziesięć lat, a taką, która co kwartał wraca do poprawek, powstaje w kilkunastu decyzjach podejmowanych bez kompletu informacji: przy doborze aparatury, przy układaniu struktury programu i na obiekcie o dwudziestej drugiej, kiedy nie ma już kogo zapytać. Tam widać kompetencję, nie w certyfikacie.
Programowanie sterownika jest warunkiem wejścia, nie kompetencją
Języki programowania sterowników opisuje norma IEC 61131-3 i opanowanie któregoś z nich zajmuje rozsądnej osobie kilka miesięcy. To jest próg, od którego rozmowa się zaczyna, a nie argument.
Kompetencja zaczyna się dalej. Na umiejętności przeczytania schematu technologicznego i zrozumienia, po co ten zawór tam jest. Na wiedzy, w które położenie ma pójść przy zaniku zasilania i dlaczego akurat w to. Na znajomości przepisów, które obowiązują w danej branży, zanim ktoś o nich przypomni na odbiorze. I na czymś, czego nie ma w żadnym programie studiów: na rozmowie z kierownikiem zmiany, który wie o tej instalacji rzeczy, których nie ma w dokumentacji, ale powie je tylko komuś, kto go o nie zapyta.
Momenty, w których jedna osoba przesądza o wyniku
Projekt automatyki ma kilka punktów, w których decyzja zapada szybko, często jednoosobowo, a jej skutki ciągną się latami.
| Moment | Co się rozstrzyga | Cena złej decyzji |
|---|---|---|
| Specyfikacja aparatury | Zakres pomiarowy, materiał, stopień ochrony, sposób zabudowy | Wymiana przetwornika w ruchu albo życie z pomiarem, któremu nikt nie ufa |
| Struktura programu | Podział na moduły, nazewnictwo, sposób obsługi stanów awaryjnych | Każda kolejna zmiana droższa od poprzedniej, aż nikt nie chce tego dotykać |
| Zachowanie przy utracie sygnału | Co robi układ, gdy znika pomiar, zasilanie albo komunikacja | Postój, a w gorszym wariancie szkoda w procesie albo w aparacie |
| Funkcje bezpieczeństwa | Czy zostały zweryfikowane, czy tylko sprawdzone „na oko” | Wypadek i odpowiedzialność, której nie da się przenieść na dostawcę |
| Decyzja na obiekcie pod presją | Uruchamiać dalej czy zatrzymać do wyjaśnienia | Najdroższa pomyłka w całym zestawieniu i podejmowana najszybciej |
| Przekazanie po zakończeniu | Co zostaje w zakładzie: kopie, opisy, dostęp | Trwałe uzależnienie od jednej firmy przy każdej drobnej zmianie |
Pierwszy wiersz jest tym, na którym zakłady tracą najwięcej pieniędzy w skali dekady, a jednocześnie tym, który najłatwiej przeoczyć przy podpisywaniu umowy. Rozpisaliśmy go osobno w tekście o tym, jak zła specyfikacja aparatury AKPiA generuje koszty przez całe życie instalacji.
Dług techniczny w sterowniku, którego nie widać do pierwszej awarii
Program można napisać tak, że działa, i tak, że działa oraz da się go zrozumieć za pięć lat. Z zewnątrz wygląda to identycznie. Różnicę widać dopiero w nocy, kiedy linia stoi, a przy laptopie siedzi ktoś, kto tego nie pisał.
Typowe objawy długu technicznego w programie sterownika są zawsze te same. Wartości wpisane na sztywno w kilkunastu miejscach zamiast w jednym parametrze. Zmienne o nazwach w rodzaju „pomocnicza3″. Ta sama logika powtórzona w trzech blokach, z czego dwa ktoś kiedyś poprawił, a trzeci nie. Komentarze po angielsku w zakładzie, w którym nikt z utrzymania ruchu nie mówi po angielsku. Brak jakiegokolwiek śladu, która wersja jest aktualna, poza datą w nazwie pliku.
Skala tego problemu jest większa, niż sugeruje jego niewidoczność. Według PLCopen, organizacji zrzeszającej producentów sterowników i twórców oprogramowania, oprogramowanie pochłania często połowę początkowych kosztów projektu, a utrzymanie odpowiada za 40 do 80 procent kosztów w całym cyklu życia. Z tego powodu powstały wytyczne kodowania PLCopen: kilkadziesiąt reguł dotyczących nazewnictwa, komentowania i struktury kodu, niezależnych od marki sterownika. Pytanie, czy wykonawca w ogóle stosuje jakikolwiek standard kodowania, kosztuje jedno zdanie na spotkaniu i mówi o nim więcej niż lista referencji.
Presja terminu jest testem kompetencji, nie charakteru
„Musimy ruszyć w piątek” to zdanie, które pada na każdym rozruchu. Inżynier słyszy je w momencie, gdy jeden test wypadł niejednoznacznie, a wyjaśnienie zajęłoby pół dnia.
Osoba niedoświadczona ma wtedy dwie odruchowe reakcje: pójść dalej, bo pewnie nic się nie stanie, albo zatrzymać wszystko i czekać na decyzję kogoś wyżej. Kompetencja polega na trzeciej możliwości: nazwać ryzyko konkretnie, powiedzieć, ile kosztuje jego sprawdzenie, ile kosztuje jego zignorowanie, i zaproponować wariant pośredni. Uruchomienie w ograniczonym zakresie, praca pod nadzorem przez pierwszą dobę, blokada jednego trybu do czasu weryfikacji. To nie jest kwestia odwagi, tylko doświadczenia w podobnych sytuacjach. Tego się nie nadrabia zdolnościami.
Po czym poznać kompetencję przed podpisaniem umowy
Referencje mówią, że firma coś wykonała. Nie mówią, kto to wykonał ani czy ta osoba nadal tam pracuje. Kilka pytań, które warto zadać na spotkaniu:
- Kto konkretnie poprowadzi ten projekt i ile obiektów w naszej branży ma za sobą?
- Czy możemy zobaczyć fragment przekazywanego programu z innego wdrożenia, choćby z zanonimizowanymi nazwami?
- Jak dokumentujecie zmiany wprowadzane w trakcie rozruchu i co trafia potem do dokumentacji powykonawczej?
- Co zostaje u nas po zakończeniu: kopie programów, licencje, opisy zmiennych, dostęp do konfiguracji?
- Kto przyjedzie przy awarii o drugiej w nocy w niedzielę i w jakim czasie?
- Co poszło nie tak na ostatnim podobnym wdrożeniu?
Ostatnie pytanie jest najbardziej użyteczne. Odpowiedź „wszystko poszło dobrze” oznacza albo brak doświadczenia, albo brak szczerości, i obie te rzeczy kosztują tyle samo.
Druga strona: poleganie na jednej osobie też jest ryzykiem
Skoro kompetencja konkretnego inżyniera waży aż tyle, to zależność od niego jest problemem samym w sobie. Zakład, w którym jedna osoba jako jedyna rozumie nowy system, jest o jedno wypowiedzenie od poważnego kłopotu.
Dlatego dobry wykonawca sam dąży do tego, żeby jego rola malała: pisze program tak, żeby przejął go ktoś inny, szkoli więcej niż jedną osobę po stronie zakładu i zostawia dokumentację, która pozwala pracować bez niego. To dokładnie ten sam mechanizm, który opisaliśmy przy warunkach decydujących o realnych wynikach projektów automatyki: kompetencja po stronie wykonawcy i warunki po stronie zakładu muszą wystąpić razem, bo żadna z tych rzeczy osobno nie wystarczy. Przy modernizacjach starszych instalacji widać to szczególnie wyraźnie, o czym pisaliśmy w tekście o roli integratora automatyki przy modernizacji starszych systemów.
Szukacie wykonawcy i chcecie sprawdzić, z kim będziecie pracować?
Napisz do nas przez formularz poniżej. Opisz krótko, co planujecie i w jakim terminie, a odpowiemy konkretnie: kto z naszej strony poprowadziłby taki projekt, jakie ma za sobą obiekty i jak wygląda to, co zostaje w zakładzie po zakończeniu prac. Zakres tego, czym się zajmujemy, jest zebrany na stronie naszych kompetencji. Jeśli uznamy, że temat lepiej poprowadzi ktoś inny, powiemy to od razu.
