(nudne, przemysłowe, hermetyczne)
Zdaje się, że ostatnio widuję w pracy już zupełnie na serio to, o czym pare razy
pisałem na blogu, a mądrzy ludzie dawno mówili - że młodsze pokolenie ma przewagę myślenia asocjacyjnego nad analitycznym; co skrzyżowane ze zdolnością skupienia na poziomie 3s i ogólnym brakiem wiedzy, generuje coś jakby cyrk skrzyżowany z wariatkowem, zamiast jakiejś namiastki inżynierii.
A miało być tak pięknie, młodzi mieli być tacy wszechstronni, przetwarzać równolegle i pracować "bazodanowo", plus mieli posiąść niezwykłe skille komputerowo-wyszukiwarkowe, że tak powiem. Bo przecież obecny gimbus jest bardziej kumaty niż zeszłowieczny inżynier, co nie?
Otóż niekoniecznie. No może w temacie lajków, fejsbunia i kotków na cyckach w internetach, to owszem, ale tak normalnie, to nie.
Wracając do roboty - wyzwalaczem notki było kilka kolejnych zderzeń z kołorkerami, przy których odkrywałem (w sensie - jak koparka wieloczerpakowa w Bełchatowie) kolejne pokłady już nawet nie nieogarnięcia czy braków w inżynierii, ale jakbym alienów odkrywał. Bo ostatnio dla trzech osób i trzech tematów, odkryłem, jak bardzo nie potrafią projektować i analizować. Like, czegokolwiek i tak po prostu.
Dla przypomnienia, definicja projektowania w inżynierii (a może nawet nieco ogólniej), to stworzenie opisu/planu/schmatu/itp OBIEKTU, złożonego z elementów/procesów niższego rzędu, który ma spełniać ZADANIE, wyrażone ZAŁOŻENIAMI i OGRANICZENIAMI, we wskazanym ŚRODOWISKU.
No więc okazało się, że młodzi kołorkerzy miewają wizję ZADANIA, czasami jakimś cudem znają i/lub istnieją szczątkowe ZAŁOŻENIA, a czasem nawet mglista wizja ŚRODOWISKA. A wiecie na czym się absurdalnie i podstawowo wykładają? Na OGRANICZENIACH i ich analizie.
Co wydaje mi się, jako domorosłemu projektantowi, majsterkowiczowi i inżynierowi tak bardzo niemożliwe, że sam nie za bardzo wierzę w to co widuję i co opisuję. Bo w moim świecie od OGRANICZEŃ i ich analizy się zaczyna, nieprawdaż, i to niekoniecznie planowanie systemu sterowania, ale jakiekolwiek planowanie czegokolwiek. Ale w ich synergiczno-holistyczno-asocjacyjnym świecie niekoniecznie.
Dobra, przejdę do konkretów może, żeby wam też mogły szczeny poopadać.
Na przykład młody siedzi nad malutkim projektem podłączenia paru klocków do sterownika PLC (Modicon ze średniej półki) - główny temat to telemetria, dwa odległe mierniki energii (dosyć egzotyczne i ściśle wyspecyfikowane), po fieldbusie klasy "Modbus over RS485". Nagle klient sobie przypomniał, że obok mierników potrzebuje parę wejść (jakiś alarm itp), więc żeby zaoferować "przy okazji" coś do tego. A dla ustalenia uwagi, poza rzeczonym fieldbusem, skądinąd po światłowodzie, między obiektami leży też net TCP/IP, do zupełnie innych celów, no ale jest to też jakaś alternatywa.
I co się dzieje? Otóż młody natychmiast utonął w asocjacyjnym morzu możliwości i kombinacji - bo nawet w tak mikroskopijnym projekcie i wątłych założeniach, można te dodatkowe wejścia podpiąć na kilka sposobów, kilkunastoma klockami od kilku producentów, a wszystko w cenach i problemach różnych. Co daje przestrzeń w miarę sensownych rozwiązań rzędu, na oko, 4 do 4, czyli należałoby przeanalizować ze 200 rozwiązań. Do czego młody zabrał się ochoczo, ale po bodaj dwu dniach zmęczył się, szczególniej, że nieco brakuje mu doświadczenia i wiedzy (czy mówiłem, że musi guglać, ile milisekund ma sekunda?), o jego średnim czasie skupienia się na zadaniu nie mówiąc. Po tych dwu czy trzech dniach zapytał mnie o pomoc, powiedzmy 10 min zajęło mu wyjaśnienie, o co kaman. No to go pytam grzecznie, czemu zajmuje się wszystkim i niczym i skacze po rozwiazaniach tak i siak, i czy nie widzi OGRANICZEŃ dla tych wszystkich kombinacji??? Otóż zeznał, że nie widzi i o co mi biega?
Udało mu się przeoczyć, że przech... mierniki (BTW made in South Africa, dołączona instrukcja po włosku...) są od strony fieldbusa prymitywne jak coś prymitywnego i razem z nimi, po jednej sieci, pójdzie niewielki procent rozważanych rozwiązań. A po TCP/IP idą dosyć skomplikowne "obce" rzeczy, nie bedące w "naszej" gestii, więc możliwe problemy z adresacją, rutingiem, itp, też mocno ograniczają ewentualności, jeśli wybrać TCP/IP (plus przeoczył, że na dzieńdobry dopłata do PLC, bo nie ma wolnego portu TCP/IP).
Serio, musiałem mu to palcem pokazywać.
(Potem jeszcze dostał zjebkę za oszukiwanie, ale to bez związku z powyższym; drążyłem temat RS485 i czy ma jakiś wzorcowy kod czy template od strony PLC do tych mierników, bo to nam dosko pokaże dokładne OGRANICZENIA dla możliwych ekspanderów, na co pokazał mi dosyć dziwny kawałek - przyciśnięty zeznał, że to jego własny draft i próby, wyjęte z dupy, a nie jakiś działający czy wzorcowy kod)
A następnego dnia przychodzi do mnie człenio po pomoc w temacie napędów (bo za guru od tego robię, gdyż takich tematów nikt tu nie ogarnia) - ma podmienić jakiś zabytek na nówkę falownik ABB, moce śmieszne, aplikacja prosta jak cep. Przygotowany do dyskusji, książki od starego i nowego falownika, zgrubne listy I/O, jakieś zarysy schematu. Gadamy se parę minut, nauczam, jestem rozumiany, jest całkiem ok. Dochodzimy do wyjścia analogowego na wskaźnik zewnętrzny, pokazujący prędkość operatorowi. Dyskusja robi się na bogato, tłumaczę, że możliwości użycia i zaprogramowania wyjść w tych falownikach są najróżniejsze - jestem odpytywany tak i siak, a może tak, a może owak, i już po chwili mi coś zaświtało. Zaraz, chwilunia, przecież wymieniasz tylko falownik, rajt? Miernik zostaje stary, rajt? To jakie on ma wejście, jak stary złomek podaje tą wartość i co mamy odtworzyć, jakie jest OGRANICZENIE opcji dotyczących wyjścia AO1? no bo zaraz ci wyłożę ogólną teorię wszystkiego, a nie tylko falowników ABB.
Odpowiedź - nie wiadomo co tam lata, zupełnie i kompletnie, gdyż albowiem zapomnieli sprawdzić, spisać, a dokumentacja niekompletna i laboga.
Ej, to po co pieprzymy już 10min o tym wyjściu jak potłuczeni, skoro NIE WIADOMO co na nim ma być? I dlaczego mam deżawu jak stąd do tamtego biurka?
Trzecia historyjka dotyczyła nie tyle OGRANICZEŃ projektowych, co ogólnie analityki i trouble-shootingu. Poszło o zrzuty logów ze SCADA do pliku (kawałek skryptu w języku BASICopodobnym, w miarę typowy algorytm z cyklicznym zrzucaniem i zakładaniem nowych plików z nowymi nazwami kodującymi datę-godzinę itp. przedszkole informatyki). Tu już się nie wpierd... zbytnio między wódkę a zakąskę, gdyż nawet dopchać się było trudno - poza dwoma młodymi dołączyło dwu starych, więc tylko w przelocie rzuciłem okiem na ekran i o co kaman. Potem już tylko mamrotałem pod nosem z sąsiednim biurkiem (młody, ale nie robi za system engineera), że co to k... ma być i ilu ludzi może zajmować się jednym skryptem na pół ekranu i dlaczego nikt nie sprawdzi czy podejrzana funkcja, obracana we wszystkie strony i macana za kakę, jest w ogóle wywoływana. Gdyż mówiąc zawile i metaforycznie, analizować należy przyczyny i przyczyny przyczyn i tak aż do skutku, a nie ciagle skutki i skutki, bezskutecznie.
W sumie, I'm generous god, więc dziś pokazałem młodemu palcem gdzie i co ma sprawdzić w parametrach "eventu" wywołującego inkryminowaną funkcję, tudzież gdzie jest klawiszek help do "eventów" w tej SCADA.
Tak, wiem, najłatwiej powiedzieć, że pracuję w słabej firmie z ignorantami. Ale jednak - chyba to nie tak. Gdyż jeśli prawie wszyscy tak się zachowują i pracują (bo to było wyjątkowe spiętrzenie, ale widzę to przez lata i kontynenty i problem braku analitycznego myślenia jakby narasta) no to nie jest problem tylko tu i teraz, ale problem powszechny w inżynierii.
A co gorsze, kiedyś będzie to problem powszechy bezprzymiotnikowo.