Zarządzanie projektami automatyki: prowadzenie projektów PLC, SCADA i systemów sterowania od URS do uruchomienia

Czym jest zarządzanie projektami automatyki

Zarządzanie projektami automatyki to dyscyplina planowania, realizacji, koordynacji i dostarczania projektów automatyki przemysłowej, które instalują, konfigurują i integrują systemy sterowania (PLC, SCADA, DCS, systemy bezpieczeństwa) w zakładzie produkcyjnym lub obiekcie procesowym. Znajduje się na styku zarządzania projektami inżynieryjnymi, informatycznymi i operacyjnymi, czerpiąc z każdego z nich, ale nie sprowadzając się do żadnego z nich, ponieważ projekty automatyki mają cechy wyróżniające, których ogólne podejścia do zarządzania projektami nie adresują w pełni.

Definicja i miejsce projektów automatyki

Projekt automatyki zaczyna się w chwili, gdy firma produkcyjna decyduje o instalacji nowego sprzętu sterowania lub modernizacji istniejących systemów sterowania, a kończy się, gdy zainstalowany system pracuje bezpiecznie i niezawodnie w produkcji, spełniając wymagania eksploatacyjne zdefiniowane na początku. Zakres obejmuje zazwyczaj dobór i zakup sprzętu, konfigurację i programowanie oprogramowania, integrację z istniejącymi systemami zakładu, testy na wielu etapach, walidację bezpieczeństwa i cyberbezpieczeństwa, szkolenie operatorów oraz formalne przekazanie do eksploatacji. Typowe rodzaje projektów to instalacje greenfield (nowy zakład, bez ograniczeń historycznych), modernizacje brownfield (wymiana przestarzałych systemów sterowania przy zachowaniu ciągłości pracy zakładu), rozbudowy mocy produkcyjnych (dodawanie nowych linii produkcyjnych do istniejącej architektury automatyki) oraz modernizacje systemów bezpieczeństwa (doprowadzenie istniejących instalacji do aktualnych norm, na przykład IEC 61511 wydanie 2).

Czym projekty automatyki różnią się od zwykłych projektów produkcyjnych

Projekt automatyki nie jest zwykłym projektem produkcyjnym, mimo że odbywa się w firmie produkcyjnej. Cztery różnice mają znaczenie. Po pierwsze, produktem końcowym jest system, a nie produkt: wynikiem jest działająca architektura automatyki, a nie odrębny wyrób gotowy do sprzedaży, więc kryteria sukcesu koncentrują się na wydajności eksploatacyjnej, a nie na charakterystykach produktu. Po drugie, praca jest głęboko wielodyscyplinarna w sposób obcy zwykłym projektom produkcyjnym: mechanika, elektryka, oprogramowanie sterujące, infrastruktura IT i inżynieria procesu wszystkie muszą trafić w ten sam termin instalacji, często z różnymi wykonawcami odpowiadającymi za różne dyscypliny. Po trzecie, sekwencja walidacji jest obowiązkowa i nieodwracalna: FAT przed SAT przed uruchomieniem, bez dostępnych skrótów, ponieważ zależności fizyczne wymuszają tę kolejność. Po czwarte, wymagania bezpieczeństwa i zgodności regulacyjnej często niosą wagę regulacyjną, których inne projekty produkcyjne nie doświadczają z tym samym natężeniem: od norm bezpieczeństwa funkcjonalnego przez wymagania cyberbezpieczeństwa po regulacje sektorowe.

Czym projekty automatyki różnią się od projektów IT

Projekty automatyki bywają błędnie prowadzone jak projekty IT, ponieważ oba dotyczą oprogramowania. Różnice są znaczące. Projekty IT zazwyczaj pozwalają na iteracyjny deployment, etapowy rollout do podzbiorów użytkowników i szybkie łatki po wydaniu. Projekty automatyki wdrażają w fizycznym zakładzie, gdzie oprogramowanie steruje fizycznymi procesami z rzeczywistymi konsekwencjami: PLC z gorącą łatką w reaktorze chemicznym to nie jest ta sama kategoria zmiany co gorąca łatka w aplikacji webowej. Projekty IT można wstrzymać; działających zakładów często nie można. Porażka projektu IT wywołuje zwykle utratę danych lub niedogodność dla użytkownika; porażka projektu automatyki może wywołać incydent bezpieczeństwa, uwolnienie do środowiska lub naruszenie regulacyjne. Dlatego istnieje dyscyplina FAT-SAT-uruchomienie i dlatego jej skracanie tworzy drogie konsekwencje, których kierownicy projektów IT mogą początkowo nie rozpoznawać.

Sześć faz projektu automatyki: od URS do uruchomienia

Projekty automatyki działają według dobrze ugruntowanej sześciofazowej struktury, która stała się standardem branżowym w sektorach chemii, farmacji, spożywczym, energetyki i produkcji ogólnej. Fazy to specyfikacja wymagań użytkownika (URS), specyfikacja funkcjonalna i szczegółowa projektu (FDS, DDS), inżynieria i budowa, testy akceptacyjne u dostawcy (FAT), instalacja i testy akceptacyjne na obiekcie (SAT) oraz uruchomienie. Każda faza ma zdefiniowane wejścia, wyjścia i kryteria bramkowe, a dyscyplina egzekwowania kryteriów bramkowych między fazami jest tym, co oddziela projekty automatyki dostarczane na czas od tych, które konsumują budżet na późnych poprawkach.

Faza 1: Specyfikacja wymagań użytkownika (URS)

URS definiuje, co system automatyki ma robić z perspektywy eksploatacyjnej: cele przepustowości produkcyjnej, specyfikacje produktu, filozofię sterowania, wymagania bezpieczeństwa, ograniczenia regulacyjne, oczekiwania dotyczące interfejsu operatora oraz punkty integracji z istniejącymi systemami zakładu i systemami IT przedsiębiorstwa. Dobrze napisany URS, podobnie jak karta projektu, jest funkcjonalny, a nie techniczny: opisuje wymagany rezultat bez narzucania rozwiązania technicznego. Jakość URS jest pojedynczym najsilniejszym predyktorem wyników projektu automatyki, ponieważ każda kolejna faza dziedziczy niejednoznaczność lub kompletność tego dokumentu. Projekty pomijające URS lub traktujące go jako formalność wielokrotnie odkrywają na etapie SAT lub uruchomienia, że różni interesariusze mieli różne założenia co do podstawowej funkcjonalności, a na tym etapie koszt uzgodnienia jest o rzędy wielkości wyższy niż byłby w fazie URS.

Faza 2: Specyfikacja funkcjonalna i szczegółowa projektu (FDS, DDS)

FDS przekłada URS na projekt funkcjonalny: który PLC, który SCADA, jaka topologia sieci, jakie pętle sterowania, jakie funkcje bezpieczeństwa, jakie alarmy i jak łączą się ze sobą oraz z infrastrukturą zakładu. DDS schodzi następnie do poziomu szczegółowości technicznej potrzebnego do inżynierii i zakupów: konkretne modele sprzętu, liczby I/O, schematy okablowania, układy szaf, architektura oprogramowania, projekty ekranów HMI. Fazy FDS i DDS obejmują przeglądy projektowe z klientem, a odbiór na koniec DDS jest odpowiednikiem zamknięcia projektu w projekcie automatyki. Zmiany po tym punkcie wymagają formalnej kontroli zmian i zazwyczaj wydłużają harmonogram.

Faza 3: Inżynieria i budowa

Inżynieria i budowa obejmują zakup sprzętu, budowę szaf sterowniczych, rozwój oprogramowania (kod PLC, ekrany SCADA, logika bezpieczeństwa, konfiguracja historiana), instalację infrastruktury sieciowej oraz mechaniczną i elektryczną budowę na obiekcie. Ta faza przebiega równolegle w wielu dyscyplinach i u wielu dostawców i to właśnie tutaj koordynacja międzydyscyplinarna pochłania większość uwagi kierownika projektu. Komponenty o długim czasie dostawy zidentyfikowane w FDS (specjalne przyrządy, sterowniki z certyfikatem SIL, wyspecjalizowany sprzęt sieciowy) muszą być zamówione wystarczająco wcześnie, żeby inżynieria mogła iść dalej bez czekania na sprzęt. Rozwój oprogramowania PLC i SCADA zwykle przebiega względem DDS równolegle z zakupem sprzętu, tak żeby oba były gotowe na FAT razem.

Faza 4: Testy akceptacyjne u dostawcy (FAT)

FAT odbywa się w obiekcie dostawcy lub integratora przed wysyłką na obiekt docelowy. Kompletny system sterowania (sprzęt PLC, oprogramowanie SCADA, systemy bezpieczeństwa) jest zmontowany i przetestowany w kontrolowanym środowisku przy użyciu symulowanych wejść i wyjść. FAT waliduje, że sprzęt odpowiada DDS, że oprogramowanie poprawnie implementuje logikę funkcjonalną, że alarmy i blokady zachowują się zgodnie z projektem, że ekrany HMI prezentują informacje zgodnie ze specyfikacją oraz że integracja między podsystemami działa. FAT to ostatnia opłacalna okazja do wychwycenia usterek: poprawki na FAT kosztują z reguły dziesięć razy mniej niż te same poprawki na SAT i sto razy mniej niż poprawki odkryte podczas uruchomienia. Pomijanie lub skracanie FAT to najczęstsze źródło drogich przekroczeń w projektach automatyki.

Faza 5: Instalacja i testy akceptacyjne na obiekcie (SAT)

Po odbiorze FAT system trafia na obiekt, jest instalowany przez wykonawców mechanicznych i elektrycznych i przechodzi SAT. SAT weryfikuje, że instalacja odpowiada rysunkom, że fizyczne I/O łączy się poprawnie z przyrządami i elementami wykonawczymi, że integracja z istniejącymi systemami zakładu działa zgodnie z projektem oraz że kompletne testy funkcjonalne przechodzą w rzeczywistych warunkach instalacyjnych. Dla projektów SCADA i procesów ciągłych SAT często obejmuje wydłużony okres ciągłej pracy, zwykle od jednego do dwóch tygodni, aby zademonstrować stabilną pracę bez większych problemów. Gdy wiele podsystemów od różnych dostawców musi być testowanych razem, po indywidualnych SAT-ach uruchamia się Site Integration Test (SIT), formalnie wprowadzony w normie IEC 62381:2024, żeby potwierdzić działanie zintegrowane.

Faza 6: Uruchomienie

Ta faza to moment przejścia zwalidowanego systemu do produkcji na żywo. Zimne uruchomienie testuje systemy bez medium procesowego lub z medium neutralnym. Gorące uruchomienie stopniowo wprowadza rzeczywiste medium procesowe z dostrojeniem pętli sterowania i sekwencji oraz optymalizacją do docelowej wydajności. Uruchomienie kończy się formalnym przekazaniem do eksploatacji, co wymaga ukończenia szkolenia operatorów, dostarczenia dokumentacji (rysunki powykonawcze, instrukcje obsługi, procedury utrzymania ruchu), dostępności części zamiennych oraz spełnienia uzgodnionych kryteriów akceptacji. Okresy wsparcia po uruchomieniu (zazwyczaj od 30 do 90 dni) pozwalają integratorowi zaadresować problemy, które ujawniają się tylko w rzeczywistych warunkach produkcyjnych.

Kręgosłup walidacji: FAT, SAT, SIT i uruchomienie

Etapy walidacji między końcem inżynierii a początkiem stabilnej produkcji tworzą definiującą dyscyplinę zarządzania projektami automatyki. Ich kolejność jest obowiązkowa i nie da się jej skrócić: sprzęt i oprogramowanie muszą najpierw zostać zwalidowane w kontrolowanym środowisku (FAT), następnie zweryfikowane w środowisku instalacyjnym (SAT), następnie zintegrowane z sąsiednimi podsystemami (SIT), następnie potwierdzone w rzeczywistych warunkach procesowych (uruchomienie). Każdy etap ma inne cele, inne kryteria akceptacji i dramatycznie różną ekonomikę wychwytywania i naprawiania usterek.

FAT: wychwytywanie usterek w najtańszym punkcie

Factory Acceptance Testing odbywa się w obiekcie dostawcy z klientem lub niezależnym inspektorem obecnym na miejscu. Kompletny system sterowania, lub funkcjonalnie kompletny podzbiór, jest zmontowany na stanowisku testowym dostawcy i uruchamiany względem symulowanego środowiska zakładu przy użyciu symulatorów I/O, stymulacji HMI oraz skryptów testów funkcjonalnych wyprowadzonych z FDS. Typowy zakres FAT obejmuje weryfikację I/O i sprawdzenie pętli (każdy kanał wejściowy i wyjściowy działa i jest poprawnie zmapowany), testy logiki sterowania i funkcjonalne (blokady, zezwolenia, alarmy, sekwencje operacji zwalidowane względem P&ID i specyfikacji funkcjonalnej), inspekcję sprzętu i okablowania (wymiary szaf, oznakowanie przewodów, uziemienie, montaż komponentów), sprawdzenie kalibracji i przyrządów oraz walidację cyberbezpieczeństwa dla systemów podłączonych do sieci. Prawidłowo przeprowadzony FAT zajmuje zwykle od jednego do pięciu dni w obiekcie dostawcy w zależności od złożoności systemu. Uzasadnienie ekonomiczne dla rzetelnego FAT jest jasne: korygowanie usterek w fabryce kosztuje zazwyczaj o rzędy wielkości mniej niż korygowanie ich w terenie, ponieważ korekta w fabryce nie ma wpływu na harmonogram zakładu, nie generuje kosztów logistyki obiektowej, nie zakłóca eksploatacji i nie wymaga ponownej mobilizacji brygad.

SAT: weryfikacja rzeczywistej instalacji i integracji

Site Acceptance Testing odbywa się po instalacji w obiekcie klienta. Potwierdza, że instalacja odpowiada rysunkom, że fizyczne I/O łączy się poprawnie z przyrządami i elementami wykonawczymi w rzeczywistym zakładzie, że integracja z istniejącymi systemami zakładu (procesy poprzedzające i następujące, interfejsy MES, ERP) działa zgodnie z projektem oraz że kompletne testy funkcjonalne przechodzą w rzeczywistych warunkach instalacyjnych. SAT często ujawnia problemy, których FAT nie mógł: źle podłączone przyrządy, niepoprawne konfiguracje urządzeń polowych, niezgodności integracyjne z systemami dziedziczonymi, zakłócenia elektromagnetyczne od sąsiedniego wyposażenia. SAT dla instalacji SCADA i procesów ciągłych zwykle wymaga wydłużonego przebiegu stabilnościowego od jednego do dwóch tygodni, żeby wykazać, że system pracuje ciągle bez większych problemów. Odbiór SAT to bramka do uruchomienia.

SIT: integracja wielu podsystemów

Nowoczesne obiekty przemysłowe rzadko opierają się na jednej platformie automatyki. Typowy zakład procesowy integruje wiele PLC, sterowniki DCS, systemy bezpieczeństwa procesowego, systemy detekcji pożaru i gazu, urządzenia pakietowe, centra sterowania silnikami, przemienniki częstotliwości, analizatory, elektryczne systemy zabezpieczeń, historiany, systemy zarządzania majątkiem oraz stacje operatorskie, często dostarczane przez różnych dostawców. Każdy podsystem może przejść FAT i SAT indywidualnie, ale gdy systemy zaczynają wymieniać rzeczywiste dane procesowe, często pojawiają się problemy integracyjne. Site Integration Testing (SIT), formalnie wprowadzony jako standardowy etap w IEC 62381:2024, testuje wszystkie podsystemy automatyki pracujące razem jako jedno rozwiązanie sterowania procesem. SIT jest właściwą odpowiedzią na złożoność wielodostawczą, której indywidualne FAT i SAT nie adresują.

Uruchomienie: potwierdzanie gotowości do produkcji na żywo

Uruchomienie przenosi zwalidowany system do produkcji na żywo. Zimne uruchomienie uruchamia system bez medium procesowego lub z nieszkodliwymi substancjami zastępczymi: pompy pracują, zawory wykonują ruchy, sekwencje się realizują, alarmy się generują, ale żaden produkt nie jest zagrożony. Gorące uruchomienie stopniowo wprowadza rzeczywiste medium procesowe, dostrajając pętle sterowania (parametry PID, konfiguracje kaskadowe, wyprzedzenia sprzężenia) i optymalizując sekwencje (receptury wsadowe, procedury rozruchu i wyłączenia) do docelowej wydajności. Podczas uruchomienia skumulowana jakość URS, FDS, inżynierii, FAT i SAT staje się widoczna: projekt, który zrobił wcześniejsze fazy dobrze, uruchamia się w dniach lub tygodniach, a projekt, który wcześniejsze fazy pominął lub skrócił, może spędzać miesiące na uruchomieniu, usuwając usterki, które powinny były zostać wychwycone wcześniej.

Koordynacja wielodyscyplinarna w projektach automatyki

Projekty automatyki są głęboko wielodyscyplinarne w sposób obcy pozostałym projektom produkcyjnym, gdzie zasady lean project management pomagają. Typowy projekt automatyki średniej skali angażuje co najmniej pięć odrębnych dyscyplin inżynieryjnych pracujących równolegle, często z różnych firm, wszystkie muszą trafić w ten sam termin instalacji i uruchomienia. Koordynacja przekazań między tymi dyscyplinami zajmuje większość uwagi kierownika projektu automatyki, a zmniejszanie tarć w przekazaniach to pojedynczy najważniejszy czynnik wpływający na całkowity czas trwania projektu.

Inżynieria mechaniczna i budowa

Wykonawcy mechaniczni instalują fizyczną infrastrukturę, od której zależy automatyka: rurociągi, zawory, elementy wykonawcze, mocowania silników, stojaki przyrządów, korytka kablowe. Ich prace poprzedzają sekwencyjnie instalację elektryczną i systemów sterowania, a opóźnienia w budowie mechanicznej rozchodzą się na każdą kolejną dyscyplinę. Zakres mechaniczny pokrywa także zapewnienie usług pneumatycznych i hydraulicznych, których wymagają przyrządy i elementy wykonawcze, co musi być skoordynowane z doborem i instalacją przyrządów, żeby uniknąć niezgodności na uruchomieniu.

Inżynieria elektryczna i instalacja

Wykonawcy elektryczni instalują rozdzielnice, centra sterowania silnikami, trasy kablowe, okablowanie szaf i połączenia urządzeń polowych. Ich sekwencja przebiega po budowie mechanicznej i poprzedza uruchomienie systemów sterowania. Wykonawcy elektryczni zwykle odpowiadają także za schemat uziemienia i wyrównania potencjałów, który jest krytyczny zarówno dla bezpieczeństwa (ochrona elektryczna), jak i niezawodności systemu sterowania (redukcja szumów na kablach sygnałowych). Koordynacja między wykonawcami elektrycznymi a integratorami systemów sterowania wokół harmonogramów kabli, układów szaf i list zaciskowych to stałe źródło tarć projektowych, wokół którego doświadczeni kierownicy projektów automatyki planują z wyprzedzeniem.

Inżynieria i integracja systemów sterowania

Integrator systemów sterowania odpowiada za dobór sprzętu PLC i jego programowanie, konfigurację SCADA i rozwój ekranów, projektowanie i walidację systemów bezpieczeństwa, architekturę sieci, konfigurację historiana i raportowania. To dyscyplina, która najbardziej bezpośrednio dostarcza funkcjonalności automatyki, z której będzie korzystać eksploatacja. Integratorzy systemów sterowania często zlecają konkretne elementy (programowanie systemów bezpieczeństwa, ocenę cyberbezpieczeństwa, projektowanie sieci) wyspecjalizowanym firmom, co dodaje kolejną warstwę koordynacji, którą musi zarządzać kierownik projektu.

Inżynieria sieci IT i OT

Nowoczesne systemy automatyki są zintegrowane sieciowo i wymagają dedykowanej infrastruktury sieciowej odrębnej od IT korporacyjnego, ze zdefiniowanymi interfejsami tam, gdzie się krzyżują. Inżynieria sieci IT/OT pokrywa architekturę sieci sterowania (zwykle warianty Ethernet przemysłowego), segmentację między strefą sterowania a korporacyjną, kontrole cyberbezpieczeństwa według IEC 62443, obsługę dostępu zdalnego oraz integrację z historianem zakładu i systemami MES. Inżynierowie IT/OT historycznie znajdowali się poza projektami automatyki i włączali się późno, ale nowoczesne projekty korzystają z angażowania ich od URS, ponieważ decyzje sieciowe wpływają na fizyczny projekt szaf i trasy kablowe.

Inżynieria procesu i eksploatacja

Inżynierowie procesu dostarczają filozofię sterowania, którą implementują PLC i SCADA: które pętle wymagają jakiej strategii sterowania, które blokady chronią przed jakimi trybami awarii, które alarmy operatorzy muszą widzieć. Eksploatacja dostarcza wiedzę operacyjną, która staje się zawartością URS: jak zakład rzeczywiście pracuje, co operatorzy potrzebują na ekranach, które sekwencje wymagają jakich opcji, jakie informacje diagnostyczne pomagają o trzeciej w nocy. Projekty automatyki, które utrzymują inżynierię procesu i eksploatację zaangażowaną od URS przez uruchomienie, konsekwentnie osiągają lepsze wyniki niż projekty, które traktują je jako konsultowanych interesariuszy, a nie aktywnych uczestników projektu.

Typowe pułapki w projektach automatyki

Pięć schematów porażki pojawia się wielokrotnie w projektach automatyki niezależnie od sektora, a każdy z nich da się przewidzieć i mu przeciwdziałać przy zastosowaniu określonych środków zaradczych. Nazwanie tych schematów sprawia, że stają się rozpoznawalne wcześniej w przyszłych projektach, gdy da się je przechwycić za ułamek kosztu radzenia sobie z nimi na uruchomieniu.

Niedookreślony URS przeniesiony do inżynierii

Pierwszy schemat to uznawanie URS za wczesną formalność zamiast za fundament, na którym opiera się cały projekt. URS jest szkicowany szybko, żeby odblokować inżynierię, niejednoznaczności zostają w dokumencie z założeniem, że zostaną rozwiązane później, a inżynieria idzie dalej przeciwko niedostatecznie zdefiniowanemu zestawowi wymagań. Konsekwencje ujawniają się na SAT i uruchomieniu: eksploatacja odkrywa, że system nie robi czegoś, co uznawali za oczywiste, albo robi coś, czego nigdy nie chcieli, a naprawa wymaga przeprojektowania, któremu prawidłowy URS by zapobiegł. Rozwiązaniem jest zainwestowanie czasu kalendarzowego w rzetelny URS z jednoznacznym odbiorem interesariuszy i zdefiniowanymi kryteriami akceptacji przed startem inżynierii, nawet gdy pozornie opóźnia to projekt.

Skracany lub pomijany FAT

Drugi schemat pojawia się wtedy, gdy FAT staje się opcjonalnym krokiem do skrócenia pod presją harmonogramu. Dostawca ukończył oprogramowanie, sprzęt jest zmontowany, ale klient decyduje, że FAT jest niepotrzebny, bo dostawca ma dobre testy wewnętrzne, albo że FAT można skrócić do demonstracji zamiast pełnego testu funkcjonalnego. Konsekwencje pojawiają się na SAT i uruchomieniu, gdzie każda usterka, którą FAT by wychwycił, teraz kosztuje od dziesięciu do stu razy więcej do naprawy. Środkiem zaradczym jest podejście do FAT jak do etapu niepodlegającego negocjacji niezależnie od presji harmonogramu i strukturyzowanie zakresu FAT wystarczająco konkretnie, żeby demonstracja nie mogła przejść jako test.

Luki koordynacji wielodostawczej bez SIT

Trzeci schemat zaczyna się od założenia, że indywidualne FAT-y i SAT-y dostawców są wystarczające, gdy wiele podsystemów musi ze sobą współpracować. Każdy system dostawcy przechodzi własne testy, ale interfejsy między systemami nie zostały zwalidowane razem, a problemy integracyjne ujawniają się podczas uruchomienia, kiedy ich rozwiązanie jest najdroższe. Odpowiedzią jest planowanie jawnego Site Integration Testing, gdy projekt obejmuje wiele podsystemów od różnych dostawców, oraz zdefiniowanie zakresu SIT już w URS, tak żeby dostawcy wiedzieli, że są kontraktowo zobowiązani do udziału w testach zintegrowanych, a nie tylko w walidacji własnego podsystemu.

Opóźnienia w sąsiednich branżach rozchodzące się na automatykę

Czwarty schemat to podchodzenie do czasu trwania projektu automatyki tak, jakby był on niezależny od innych branż na obiekcie. Budowa mechaniczna się przesuwa, instalacja elektryczna się przesuwa, a zespół automatyki przyjeżdża zacząć SAT tylko po to, żeby zastać zakład niegotowy do jego przyjęcia. Harmonogramy zespołu automatyki zazwyczaj nie mogą się przesunąć w tym samym kierunku, ponieważ okna uruchomieniowe są powiązane z postojami zakładu lub oknami rozruchowymi ustalonymi z dużym wyprzedzeniem. Rozwiązaniem jest integrowanie harmonogramów projektu automatyki z harmonogramami mechanicznymi i elektrycznymi w sposób jawny, z kamieniami milowymi zdefiniowanymi dla gotowości każdej branży do działań automatyki i z wyzwalaczami eskalacji, gdy dowolna branża przesuwa się poza bufor.

Odroczona walidacja bezpieczeństwa i cyberbezpieczeństwa

W piątym schemacie testy funkcjonalne bezpieczeństwa i walidacja cyberbezpieczeństwa zostają sprowadzone do formalnych czynności odbiorowych na końcu, a nie prowadzone jako ciągłe strumienie pracy przez cały projekt. Funkcje bezpieczeństwa procesowego wymagają walidacji względem specyfikacji wymagań bezpieczeństwa przez cały cykl życia, od projektu przez FAT i SAT do uruchomienia, a cyberbezpieczeństwo według IEC 62443 podobnie wymaga kontroli już na etapie projektowania, a nie audytu końcowego. Środkiem zaradczym jest zdefiniowanie strumieni pracy bezpieczeństwa i cyberbezpieczeństwa z jawnymi produktami cząstkowymi per faza, obsadzenie ich osobno od testów funkcjonalnych oraz traktowanie odbioru bezpieczeństwa i cyberbezpieczeństwa jako odrębnych bramek, a nie jako pozycji na ogólnej liście akceptacji.

Bezpieczeństwo i zgodność regulacyjna w projektach automatyki

Projekty automatyki działają w ramach regulacyjnych i normatywnych, z którymi zwykłe projekty produkcyjne rzadko spotykają się z tym samym natężeniem. Bezpieczeństwo funkcjonalne, cyberbezpieczeństwo, regulacje sektorowe i normy przemysłowe wszystkie narzucają wymagania, które muszą być wbudowane w strukturę projektu od URS, a nie doszywane na etapie uruchomienia. Porażka zgodności na przekazaniu jest w najlepszym wypadku droga, a w najgorszym blokuje eksploatację, i dyscyplina wbudowywania zgodności w przebieg projektu to jest to, co oddziela kierowników projektów automatyki dostarczających na czas od tych, którzy spędzają ostatni miesiąc na szukaniu dowodów audytowych.

Bezpieczeństwo funkcjonalne według IEC 61511 i IEC 61508

Systemy bezpieczeństwa procesowego w przemysłach procesowych podlegają IEC 61511 (z IEC 61508 jako normą podstawową). Wymagania cyklu życia to analiza zagrożeń i ryzyka, alokację funkcji bezpieczeństwa do funkcji bezpieczeństwa procesowego (SIF) z poziomami nienaruszalności bezpieczeństwa (SIL), specyfikację wymagań bezpieczeństwa, projekt i inżynierię z weryfikacją SIL, walidację instalacji i uruchomienia oraz procedury eksploatacji i utrzymania ruchu. Bezpieczeństwa nie da się dodać na uruchomieniu; musi być obecne przez każdą fazę. Projekty automatyki, które traktują bezpieczeństwo jako odrębny strumień pracy od URS, wytwarzają produkty cząstkowe gotowe do audytu jako naturalny wynik projektu, a projekty, które traktują bezpieczeństwo jako końcową czynność odbiorową, zazwyczaj odkrywają późno, że luki w dokumentacji lub problemy projektowe wymagają poprawek.

Cyberbezpieczeństwo według IEC 62443

Systemy automatyki i sterowania przemysłowego mierzą się z zagrożeniami cyberbezpieczeństwa, których frameworki bezpieczeństwa IT nie adresują w pełni. IEC 62443 definiuje wymagania cyberbezpieczeństwa dla automatyki przemysłowej, w tym segmentację sieci między strefami IT i OT, bezpieczny dostęp zdalny, zarządzanie łatkami bezpieczeństwa dla systemów sterowania, logowanie zdarzeń bezpieczeństwa oraz zarządzanie podatnościami. Wymagania cyberbezpieczeństwa muszą być zdefiniowane w URS i odzwierciedlone w FDS, DDS i inżynierii. Doszywanie cyberbezpieczeństwa na uruchomieniu jest drogie i rzadko przynosi zadowalające wyniki, ponieważ fundamentalne decyzje architektoniczne zostały już podjęte.

Regulacje sektorowe

Różne sektory przemysłu dokładają konkretne wymagania zgodności do projektów automatyki. Projekty farmaceutyczne i life sciences podlegają EU GMP Annex 15, który jawnie uznaje role FAT i SAT w kwalifikacji i wymaga udokumentowanych dowodów dla krytycznych przyrządów, kalibracji i weryfikacji procesu. FDA 21 CFR Part 11 stosuje się do zapisów i podpisów elektronicznych w life sciences. Projekty spożywcze podlegają zasadom HACCP z sektorowymi normami dla projektowania higienicznego i identyfikowalności. Projekty energetyczne i użyteczności publicznej podlegają NERC CIP dla cyberbezpieczeństwa sieci elektroenergetycznej. Projekty przemysłu ogólnego wymagają demonstracji znaku CE i stosownych norm ISO dla bezpieczeństwa, wydajności i specyfikacji technicznych. Wymagania sektorowe muszą być zidentyfikowane w URS, a harmonogram projektu musi uwzględniać czynności audytowe i dokumentacyjne, które one narzucają.

Zarządzanie wieloma projektami automatyki w skali portfela

Firma inżynieryjna dostarczająca projekty automatyki lub producent prowadzący wiele równoległych inicjatyw automatyki rzadko ma w toku pojedynczy projekt. Częściej portfel zawiera kilka projektów w różnych fazach, konkurujących o ten sam talent inżynierski, urządzenia testowe, moce integratorów i okna uruchomieniowe. Widok portfelowy to miejsce, gdzie zarządzanie projektami automatyki przechodzi z dyscypliny projektowej do zdolności organizacyjnej, i gdzie największe zyski w ogólnej przepustowości są dostępne.

Dashboard portfelowy dla projektów automatyki

Dashboard portfelowy dla projektów automatyki pokazuje wszystkie aktywne projekty pogrupowane per faza (URS, FDS, inżynieria, FAT, SAT, uruchomienie), z widocznością, które projekty zbliżają się do przeglądów bramkowych i które są zablokowane oraz ile znajduje się w każdej fazie. Dashboard ujawnia schematy, które ukrywają widoki poszczególnych projektów: systematyczne wąskie gardła przy planowaniu FAT z tym samym integratorem, okna uruchomieniowe zbierające się w wąskie pasma kalendarzowe, konkurencja o zasoby przy wyspecjalizowanych umiejętnościach takich jak programowanie systemów bezpieczeństwa. Rozpoznawanie schematów w skali portfela napędza systemowe usprawnianie zamiast reaktywnego gaszenia pożarów per projekt.

Konkurencja o zasoby na wyspecjalizowanych umiejętnościach

Projekty automatyki zależą od wyspecjalizowanych umiejętności, których często brakuje na rynku: programiści systemów bezpieczeństwa, specjaliści cyberbezpieczeństwa, architekci sieci, eksperci konkretnych platform PLC, inżynierowie uruchomienia z doświadczeniem sektorowym. Dzielone zasoby stają się największym źródłem nieplanowanych opóźnień w portfelu wielu projektów. Konkurencja o zasoby, która jest niewidoczna dla pojedynczych projektów, staje się widoczna dopiero w widoku portfela, gdzie ten sam specjalista pojawiający się w harmonogramach wielu projektów jednocześnie ujawnia podwójne rezerwowanie, którego poszczególni kierownicy projektów nie widzą. Skuteczne zarządzanie portfelem identyfikuje te ograniczenia wcześnie i albo dokłada moce, albo układa projekty w kolejność ograniczającą konkurencję, albo akceptuje opóźnienia jako świadome decyzje portfelowe.

Standaryzacja między projektami

Dojrzałe portfele projektów automatyki standaryzują powtarzalne elementy: szablony URS per typ projektu, struktury FDS, formaty skryptów testowych FAT, kryteria akceptacji SAT, listy kontrolne uruchomienia, szablony dokumentacji bezpieczeństwa, procedury oceny cyberbezpieczeństwa. Standaryzacja zapobiega wynajdywaniu koła w rutynowych elementach na każdym projekcie i uwalnia uwagę inżynierską na te części, które naprawdę się różnią. Standaryzacja umożliwia także uczenie między projektami: schemat usterki ujawniony na FAT jednego projektu aktualizuje szablony tak, żeby kolejne projekty wychwytywały tę samą klasę usterek wcześniej. Firmy inżynieryjne z dojrzałą standaryzacją dostarczają projekty szybciej i z mniejszą zmiennością niż firmy, gdzie każdy projekt wynajduje własne podejście.

Planowanie wydajności portfelowej i decyzje ofertowe

Widoczność portfelowa dotycząca bieżących obciążeń projektowych i prognozowanej dostępności zasobów wspiera decyzje handlowe, które firmy inżynieryjne podejmują nieustannie: które oferty składać, na jakie terminy dostawy się zobowiązywać, kiedy zatrudniać, kiedy powiedzieć nie konkretnym możliwościom. Firmy bez portfelowych danych o wydajności zazwyczaj przeszacowują zobowiązania w fazach optymistycznych i niedoszacowują w fazach konserwatywnych, a wynikająca z tego zmienność dostaw wpływa na relacje z klientami i retencję pracowników. Firmy z portfelowymi danymi mogą podejmować decyzje ofertowe oparte o rzeczywistą wydajność dostawczą, a nie o optymizm co do tego, ile zespół zdoła wchłonąć.

Studium przypadku A: Smart Automation, zdyscyplinowana realizacja portfelowa

Smart Automation to firma inżynieryjna z Olsztyna, obecna na rynku automatyki przemysłowej od 2009 roku. Firma projektuje i dostarcza kompletne systemy automatyki: od koncepcji maszyn i analiz wykonalności, przez programowanie układów sterowania i systemy wizyjne, po robotyzację procesów produkcyjnych i budowę maszyn specjalnych. Zespół łączy ponad 300 lat sumarycznego doświadczenia w automatyce, robotyce i mechatronice. Firma zrealizowała ponad 1000 projektów w kraju i za granicą dla klientów takich jak IKEA, Michelin, Siemens Energy, Unilever czy Danone, co w praktyce oznacza kilkadziesiąt równoległych wdrożeń w danym momencie, różniących się skalą, złożonością i lokalizacją.

Punkt wyjścia przed wdrożeniem FlexiProject był typowy dla firm inżynieryjnych: budżety prowadzono w rozwiązaniach zbudowanych wokół systemu ERP, bo tam znajdują się faktury, płatności i koszty, ale każdy kierownik projektu wypracował własny sposób kontroli finansowej. Narzędzia harmonogramowe, monitorowanie ryzyk i planowanie zasobów praktycznie nie istniały. Nie było pełnego obrazu pojedynczego projektu, a tym bardziej całego portfela. Firma zdecydowała się szukać dedykowanego systemu zarządzania projektami, który połączy harmonogramy, budżety, ryzyka i zasoby w jednym miejscu i stanie się jedynym źródłem informacji o projektach.

Wdrożenie objęło całą organizację. W trzy miesiące wszystkie 51 aktywnych projektów o różnej złożoności zostało przeniesione do FlexiProject. Z systemu korzystają dziś wszyscy pracownicy i kluczowi podwykonawcy, w sumie 37 osób, co ułatwiła elastyczna pula licencji. Co ważniejsze, firma potraktowała wdrożenie jako okazję do zbudowania wspólnego standardu zarządzania projektami, a nie tylko wymiany narzędzia. Każdy projekt zaczyna się dziś tak samo: od karty projektu definiującej cele, zakres i odpowiedzialności oraz od modelu fazowego porządkującego pracę od koncepcji po przekazanie. Harmonogramy powstają na wspólnym szablonie z zależnościami w wykresie Gantta i kamieniami milowymi, a każdy plan jest zapisywany jako plan bazowy: zatwierdzony punkt odniesienia, względem którego mierzy się odchylenia terminów i kosztów.

Dane budżetowe musiały pozostać zgodne z systemem ERP, dlatego FlexiProject zintegrowano z ERP tak, żeby informacje o kosztach przepływały między systemami bez podwójnego wprowadzania. Poza projektami elastyczna struktura pozwoliła odwzorować proces ofertowania oraz serwis gwarancyjny i pogwarancyjny. Dwa czynniki zdecydowały o adaptacji przez użytkowników. Po pierwsze, prezes wszedł w rolę aktywnego sponsora projektu, konsekwentnie wymagając, żeby wszystkie informacje o projektach znajdowały się w jednym systemie i oczekując regularnych aktualizacji od każdego kierownika projektu. Po drugie, bariera wejścia była niska: budowanie harmonogramów i budżetów okazało się na tyle intuicyjne, że każdy kierownik projektu, niezależnie od doświadczenia, mógł zaczynać szkolenie od wprowadzenia własnego, realnego projektu, a nie od ćwiczeń na sztucznych przykładach. Rezultaty widać w decyzjach: odchylenia budżetów z prognozą kosztów do zakończenia, obłożenie zasobów jako wsad do decyzji ofertowych i planów rekrutacji, przeglądy projektów co dwa tygodnie dla projektów w realizacji i co miesiąc dla projektów w fazie planowania, wszystko oparte o dane z systemu zamiast ręcznie przygotowywanych prezentacji.

Studium przypadku B: kryzys automatyzacji Tesli Model 3, 2017-2018

Rozruch produkcji Tesli Model 3 w latach 2017-2018 to jedna z najbardziej publicznie udokumentowanych porażek projektu automatyki w historii przemysłu, wyjątkowa przez gotowość Elona Muska do przyznania się do niej własnymi słowami. Model 3 został ogłoszony w 2016 roku jako pierwszy pojazd Tesli dla masowego rynku w docelowej cenie 35 000 USD, a w ciągu 24 godzin od uruchomienia rezerwacji dokonało 115 000 osób. Tesla postawiła ambitny cel produkcji 5 000 pojazdów Model 3 tygodniowo do końca 2017 roku i przyjęła to, co Musk później opisał jako podejście „zautomatyzować wszystko” w produkcji, przy założeniu, że intensywna automatyzacja umożliwi skalę wymaganą do obsłużenia zaległości przedsprzedażowych.

Rezultatem było to, co Musk sam nazwał „piekłem produkcyjnym”. Tesla nie osiągnęła celu na koniec 2017 roku z dużym marginesem, z wynikiem 2 425 pojazdów Model 3 w całym czwartym kwartale 2017 (wobec celu 5 000 tygodniowo). Zrewidowany cel na koniec pierwszego kwartału 2018 wynoszący 2 500 tygodniowo również nie został osiągnięty, a Tesla osiągnęła 2 020 w ostatnim tygodniu Q1. Linia montażowa modułów baterii w Gigafactory i końcowa linia montażowa we Fremont miały projekty automatyzacji, które okazały się zawodne w skali produkcyjnej. Analitycy Bernstein publicznie argumentowali, że nadmierna automatyzacja wbudowywała błędy Tesli w linię produkcyjną i kosztowała więcej, niż była warta. 13 kwietnia 2018 roku Musk publicznie przyznał na Twitterze: „Tak, nadmierna automatyzacja w Tesli była błędem. Mówiąc precyzyjnie, moim błędem. Ludzie są niedoceniani.” W wywiadzie dla CBS opisał demontowanie „szalonej, złożonej sieci przenośników taśmowych”, która nie działała, a Tesla ostatecznie wycofała części linii montażowej do operacji manualnych, w tym dobrze znaną tymczasową linię montażową „pod namiotem” we Fremont, która dołożyła moce produkcyjne przez pracę manualną, a nie przez dalszą automatyzację.

Trzy lekcje przenoszą się bezpośrednio na dowolny projekt automatyki. Po pierwsze, ambicja automatyzacyjna bez walidacji pilotażowej kumuluje ryzyko zamiast je redukować: decyzja Tesli o wdrożeniu nowej automatyzacji w skali produkcyjnej przed jej zwalidowaniem w skali pilotażowej zwielokrotniła trudność każdego kolejnego cyklu usuwania usterek, podczas gdy etapowy rozruch ujawniłby problemy z automatyzacją przy niższym koszcie. Po drugie, nadmierna automatyzacja etapów montażu wymagających adaptacyjności daje gorsze rezultaty niż rozwiązania półautomatyczne, w których ludzie obsługują zmienność, a maszyny obsługują pracę powtarzalną: to znana zasada praktyki produkcyjnej stosowanej w Japonii, którą Tesla w efekcie odkryła na nowo pod presją produkcyjną. Po trzecie, zobowiązania harmonogramowe przyjmujące, że technologia zadziała zgodnie z oczekiwaniami, bez odpowiedniego bufora harmonogramu na wykrycie problemów z automatyzacją, tworzą presję, która utrudnia zdyscyplinowane rozwiązywanie problemów zamiast je ułatwiać. Tesla ostatecznie osiągnęła cel 5 000 tygodniowo do końca czerwca 2018 roku, ponad podwajając całkowitą produkcję z 2017 roku, ale koszt osiągnięcia tego przez kryzys, a nie przez zdyscyplinowany rozruch, był znaczący.

Jak FlexiProject wspiera projekty automatyki

FlexiProject wspiera warstwę wykonawczą zarządzania projektami automatyki z widocznością portfelową, zarządzaniem harmonogramem, śledzeniem ryzyk, uporządkowanymi przeglądami i standaryzowanymi szablonami. Wielodyscyplinarna koordynacja projektów automatyki, zwłaszcza praca uzgadniania funkcji mechaniki, elektryki, systemów sterowania, IT/OT i inżynierii procesu, pozostaje odpowiedzialnością organizacji. FlexiProject dostarcza infrastrukturę operacyjną, która sprawia, że zdyscyplinowana realizacja projektu automatyki jest wykonalna w skali, a nie substytut dla współpracy inżynierskiej, od której zależy sukces projektu automatyki.

Widok portfelowy dla równoległych projektów automatyki

FlexiProject dostarcza dashboard portfelowy, który pokazuje wszystkie aktywne projekty automatyki w jednym widoku, pogrupowane per faza (URS, FDS, inżynieria, FAT, SAT, uruchomienie) i per klient lub linia biznesowa, z widocznością, które projekty zbliżają się do przeglądów bramkowych i które są zablokowane. Widok portfelowy uwidacznia schematy, które ukrywają widoki poszczególnych projektów, takie jak okna uruchomieniowe zbierające się w wąskie pasma kalendarzowe, konkurencja o zasoby przy wyspecjalizowanych umiejętnościach oraz systematyczne opóźnienia przy planowaniu FAT z konkretnymi integratorami. Komitety sterujące podejmujące decyzje portfelowe pracują z tego samego widoku portfelowego zamiast uzgadniać różne raporty projektowe.

Harmonogram z widokiem Gantta, listą zadań i widokiem Kanban

Harmonogram FlexiProject łączy widok wykresu Gantta do śledzenia kamieni milowych i wizualizacji zależności, widok listy zadań do szczegółowej pracy wykonawczej oraz widok Kanban do dyscypliny przepływu w ramach faz. Projekty automatyki korzystają z tego połączenia: wykres Gantta obsługuje strukturę fazową z zależnościami od URS do uruchomienia i kamieniami milowymi przeglądów bramkowych, listy zadań obsługują szczegółową pracę inżynieryjną i testową w fazach, a Kanban śledzi przepływ konkretnych produktów cząstkowych przez przegląd i akceptację. Ikony ostrzegawcze na zadaniach harmonogramu sygnalizują problemy budżetowe lub ryzykowne bez konieczności osobnych raportów.

Rejestr ryzyk powiązany z fazami projektu

Rejestr ryzyk w FlexiProject śledzi ryzyka specyficzne dla automatyki z właścicielami, planami ograniczania ryzyka i rytmem przeglądu. Ryzyka fazowe (dostępność komponentów o długim czasie dostawy podczas inżynierii, gotowość dostawcy do FAT, gotowość obiektu do SAT, dostępność zakładu do uruchomienia, walidacja systemów bezpieczeństwa, ocena cyberbezpieczeństwa) są powiązane z odpowiednimi kamieniami milowymi faz i przeglądane na odpowiedniej bramce. Powiązanie między ryzykami, zadaniami a harmonogramem oznacza, że materializujące się ryzyko widocznie wpływa na powiązaną oś czasu zamiast pozostawać w oddzielnym rejestrze, do którego nikt nie zagląda podczas decyzji harmonogramowych.

Przeglądy projektu jako przeglądy bramkowe

Przeglądy projektu w FlexiProject mogą być strukturyzowane jako formalne przeglądy bramkowe projektu automatyki z określonymi kryteriami, uporządkowaną prezentacją dowodów oraz formalnymi decyzjami tak lub nie zapisanymi w rekordzie projektu. Rytm przeglądów jest zaplanowany (zazwyczaj na koniec każdej fazy projektu i przy każdym przejściu FAT/SAT/uruchomienie), a wyniki przeglądów zasilają standaryzowane szablony dla kolejnych projektów. Kryteria bramkowe skonfigurowane w szablonach są stosowane spójnie w projektach tego samego typu, więc bramka odbioru FAT jednego projektu używa tej samej struktury kryteriów co bramka odbioru FAT innego projektu.

Standaryzowane szablony projektów automatyki

FlexiProject dostarcza standaryzowane szablony dla powtarzalnej struktury projektu automatyki, z modelem sześciofazowym, kręgosłupem walidacji FAT-SAT-uruchomienie, standardowymi produktami cząstkowymi per faza oraz standardowymi kryteriami bramkowymi odpowiednimi dla automatyki. Firmy inżynieryjne mogą rozszerzać szablony na podstawie specyfiki typu projektu (greenfield, modernizacja brownfield, rozbudowa mocy, modernizacja bezpieczeństwa) bez porzucania podstawowej struktury. Zarządzanie projektami automatyki oparte o szablony działa jako cyfrowy odpowiednik standaryzowanej praktyki inżynierskiej: zapobiega wynajdywaniu koła w rutynowych elementach projektu i uwalnia uwagę inżynierską na te części każdego projektu, które naprawdę się różnią.

Czego FlexiProject nie robi

FlexiProject nie wykonuje inżynierii (to praca integratora systemów sterowania), nie realizuje FAT ani SAT (te wymagają stanowisk testowych i aparatury), nie kwalifikuje dostawców (to wymaga procesów zakupów i jakości) ani nie zastępuje dyscypliny egzekwowania kryteriów bramkowych (to wymaga zaangażowania kierownictwa). Dostarcza widoczności, struktury i możliwości śledzenia, które sprawiają, że zdyscyplinowana realizacja projektu automatyki jest wykonalna w portfelu, ale sama dyscyplina jest organizacyjna.

Najczęściej zadawane pytania

Jaka jest różnica między zarządzaniem projektami automatyki a ogólnym zarządzaniem projektami?

Ogólne zasady zarządzania projektami stosują się do projektów automatyki, ale projekty automatyki mają cechy wyróżniające, których ogólne podejścia nie adresują w pełni: obowiązkowy sekwencyjny kręgosłup walidacji (FAT przed SAT przed uruchomieniem), wielodyscyplinarna z założenia złożoność w mechanice, elektryce, oprogramowaniu sterującym, IT/OT i inżynierii procesu, wymagania bezpieczeństwa i zgodności z wagą regulacyjną oraz zależność od wielu zewnętrznych dostawców, których opóźnienia rozchodzą się w sposób trudny do przewidzenia. Kierownicy projektów automatyki zwykle mają wykształcenie inżynieryjne i konkretne doświadczenie sektorowe, ponieważ techniczna zawartość decyzji wpływa na wyniki projektu na poziomie, którego ogólne zarządzanie projektami nie zastąpi.

Ile trwa typowy projekt automatyki?

Zależy od zakresu, złożoności i sektora. Prosta instalacja greenfield z ograniczoną integracją może ukończyć się w sześć do dziewięciu miesięcy. Typowa modernizacja brownfield z integracją do istniejących systemów zakładu zajmuje zwykle od dwunastu do osiemnastu miesięcy. Duże projekty inwestycyjne z nową technologią lub elementami krytycznymi dla bezpieczeństwa mogą trwać dwa do trzech lat. Pojedynczym największym czynnikiem harmonogramowym często nie jest złożoność inżynierska, ale złożoność koordynacyjna: projekty z wieloma dostawcami i dyscyplinami trwają dłużej niż projekty z mniejszą liczbą stron, nawet gdy praca techniczna jest podobna.

Kto jest właścicielem projektu automatyki?

Kierownik projektu automatyki jest właścicielem harmonogramu, koordynacji, przeglądów bramkowych i uzgadniania międzydyscyplinarnego, ale praca jest wielodyscyplinarna w swej istocie i żadna pojedyncza funkcja jej nie kontroluje. Wykonawcy mechaniczni są właścicielami fizycznej infrastruktury, wykonawcy elektryczni są właścicielami zasilania i okablowania, integrator systemów sterowania jest właścicielem dostarczenia PLC i SCADA, inżynierowie IT/OT są właścicielami infrastruktury sieciowej, inżynierowie procesu są właścicielami filozofii sterowania, a eksploatacja jest właścicielem wymagań, które system musi spełnić. Kierownik projektu automatyki jest koordynatorem i integratorem między tymi funkcjami. Sponsor na poziomie zarządu jest niezbędny, ponieważ decyzje bramkowe mają implikacje handlowe i bezpieczeństwa, które wykraczają poza uprawnienia kierownika projektu.

Jaka jest różnica między FAT a SAT?

FAT (Factory Acceptance Testing) jest wykonywany w obiekcie dostawcy lub integratora przed wysyłką na obiekt docelowy, przy użyciu symulowanych wejść i wyjść do walidacji sprzętu i oprogramowania w kontrolowanym środowisku. SAT (Site Acceptance Testing) jest wykonywany w obiekcie klienta po instalacji, weryfikując, że instalacja odpowiada rysunkom, że fizyczne I/O łączy się poprawnie z rzeczywistymi przyrządami i elementami wykonawczymi, oraz że integracja z istniejącymi systemami zakładu działa. FAT wychwytuje usterki w najtańszym punkcie cyklu życia; SAT łapie problemy, które ujawniają się tylko w rzeczywistym środowisku instalacyjnym. Żaden nie może zastąpić drugiego i oba są zazwyczaj niezbędne.

Czy FAT i SAT są wymagane regulacyjnie?

Zależy od sektora. Projekty farmaceutyczne i life sciences faktycznie wymagają FAT i SAT na mocy EU GMP Annex 15, który jawnie uznaje ich role w kwalifikacji. Dla ogólnego wyposażenia przemysłowego znak CE i stosowne normy ISO wymagają demonstracji, że wyposażenie spełnia specyfikacje bezpieczeństwa, wydajności i techniczne, a FAT i SAT są standardowymi mechanizmami wytwarzania tej demonstracji. Nawet tam, gdzie nie są ściśle wymagane regulacyjnie, FAT i SAT są standardową praktyką w większości sektorów przemysłowych, ponieważ uzasadnienie ekonomiczne wychwytywania usterek w możliwie najwcześniejszym punkcie jest dobrze ugruntowane.

Czy projekty automatyki mogą działać według metod Agile?

Projekty automatyki mają zależności fizyczne, które ograniczają stosowalność czystych metod Agile: sprzęt wymaga czasu dostawy, uruchomienie wymaga okien dostępności zakładu, walidacja bezpieczeństwa przebiega według sekwencji regulacyjnych, których nie da się iterować. Elementy myślenia Agile sprawdzają się dobrze, w szczególności iteracyjne doprecyzowywanie URS z interesariuszami przed zamknięciem projektu i stopniowe usuwanie usterek podczas FAT i uruchomienia. Ale struktura fazowa od URS do uruchomienia to kręgosłup kaskadowy, ponieważ ograniczenia fizyczne i regulacyjne go wymuszają, a próby stosowania czystych metod Agile do projektów automatyki zazwyczaj osiągają gorsze wyniki niż zdyscyplinowane podejście fazowo-bramkowe.

Zarządzanie projektami automatyki to dyscyplina realizacji projektów automatyki przemysłowej od specyfikacji wymagań użytkownika przez inżynierię, FAT, SAT i uruchomienie do stabilnej produkcji, odrębna od ogólnego zarządzania projektami produkcyjnymi przez swój obowiązkowy sekwencyjny kręgosłup walidacji, głęboko wielodyscyplinarną złożoność, natężenie wymagań bezpieczeństwa i zgodności oraz zależność od koordynacji wielodostawczej. Sześciofazowa struktura od URS do uruchomienia dostarcza ramy, a kręgosłup walidacji FAT-SAT-SIT-uruchomienie dostarcza definiującej dyscypliny, przy czym usterki wychwycone na FAT kosztują o rząd wielkości mniej niż na SAT i o dwa rzędy wielkości mniej niż podczas uruchomienia. Koordynacja wielodyscyplinarna między funkcjami mechaniki, elektryki, systemów sterowania, IT/OT i inżynierii procesu pochłania większość uwagi kierownika projektu, a zmniejszanie tarć w przekazaniach to pojedynczy najważniejszy czynnik wpływający na całkowity czas trwania projektu. Pięć schematów porażki (niedookreślony URS, skracany FAT, luki koordynacji wielodostawczej bez SIT, opóźnienia sąsiednich branż rozchodzące się na automatykę, odroczone bezpieczeństwo i cyberbezpieczeństwo) można przewidzieć i przechwycić dzięki nazwanym środkom zaradczym. Wymagania bezpieczeństwa i zgodności, w tym IEC 61511, IEC 62443 i regulacje sektorowe, muszą być wbudowane w przebieg projektu od URS. Widoczność portfelowa równoległych projektów automatyki umożliwia decyzje o zasobach, standaryzacji i wydajności, które firmy inżynieryjne podejmują nieustannie. Przypadek Smart Automation pokazuje, że średnia firma inżynieryjna może w kilka miesięcy zbudować zdyscyplinowany standard projektowy wokół wspólnego systemu, a przypadek Tesla Model 3 pokazuje, że ambicja automatyzacyjna bez walidacji pilotażowej i zdyscyplinowanej realizacji fazowo-bramkowej prowadzi do „piekła produkcyjnego” w największej możliwej skali. FlexiProject wspiera warstwę wykonawczą zarządzania projektami automatyki z widocznością portfelową, zarządzaniem harmonogramem łączącym widoki Gantta, listy zadań i Kanban, rejestrem ryzyk powiązanym z fazami, uporządkowanymi przeglądami w roli przeglądów bramkowych oraz standaryzowanymi szablonami projektów. Wielodyscyplinarna koordynacja inżynieryjna i zdyscyplinowane egzekwowanie kryteriów bramkowych pozostają odpowiedzialnościami organizacji. Jeśli portfel projektów automatyki firmy inżynieryjnej wyrósł poza arkusze i potrzebuje systemu wspierającego dyscyplinę w wielu równoległych projektach i międzydyscyplinarnych zespołach, trzydzieści dni pełnego dostępu bez karty kredytowej to praktyczny sposób, żeby to sprawdzić.