Licencja

Ostatnie wpisy:


Ostatnie komentarze:

Codiac - Zakazane piosenki
Mon, 10 Dec 2018 15:46
Wpadło mi dzisiaj coś takiego. Może nie jest to coś...

Boni - Premium
Wed, 14 Nov 2018 13:35
@zz_top Tak szczerze, to nie ogarniam i nie wnikam,...

zz_top - Premium
Wed, 14 Nov 2018 08:52
Ej, ale czemu ty jako premium szukasz w Audi A7 czy...

Boni - Premium
Wed, 14 Nov 2018 03:11
Obejrzałem sobie różności i powiedzmy, chyba...

Boni - Premium
Tue, 13 Nov 2018 20:24
@zz_top A to faktycznie porażka. Powiedzmy, dalsze...

zz_top - Premium
Tue, 13 Nov 2018 20:07
Nawet mnie zaciekawiłeś tą germańską trójcą i...

Boni - Premium
Tue, 13 Nov 2018 19:47
@zz_top Zapewne masz rację, tyle że z merolami ze...

zz_top - Premium
Mon, 12 Nov 2018 16:29
Na fali oglądania nowego nabytku znajomego (Mercedes E...

Boni - Historie renesansowe
Mon, 5 Nov 2018 09:32
@Gammon Pewnie tak, gdzieś tam były używane....

Gammon No.82 - Historie renesansowe
Mon, 5 Nov 2018 06:11
Czy mi się śni, czy morskie armaty z brązu bywały w...


Rollka:

Blog de Bart
Ceàrdach
Co lepsze kawałki
Ekskursje w dyskursie
Inżynieria Wszechświetności
Nameste blog
Ogólna teoria
pattern recognition
Polska-NRD-Niemcy-Świat
snafu
Teklak
Utilitymon
Wrzutnia nocna

Inne:

inSitu - pudełko z obrazkami
Eat me. Drink me.
Szrot nasz codzienny
EVA prawdé ci powié
PolitMap



Valid HTML 4.01 Strict

Valid CSS

powered by PHP

Wpisy    Losowo    Autor    Rejestracja    Zgłoś błąd
RSS blog   RSS komentarze







Autor: Boni
Kiedy: 2018-08-20, poniedziałek
Tagi:  przemysł, hejt
___________________________________
Po ostatnim tygodniu uleję sobie troszeczkę na okolice pracy, czyli jak zwykle, nudna automatyka przemysłowa itp.

W komplecie do zagadnień poruszanych w notce o ogólnie zbędnym przekombinowaniu nowożytnego IT, więc i automatyki, (znowu) ponarzekam na trochę bardziej szczegółowy temat, czyli łączności i networking w automatyce. Gdyż jakiś czas temu, w dyskusji w pracy ustaliliśmy, że problemy łączności i osieciowania wszystkiego zajmują nam jakieś 40-80% czasu pracy w nieco bardziej skomplikowanych projektach. 40% to jeśli dostawcy komponentów i ich łączności nie są totalnymi zjebami a nasz klient głupi, bo w marketingowe ściemy sprzedawców tych komponentów uwierzył. 80% to jeśli klient się upiera, że jakiś feature "ma działać", a dostawca akurat się poślizgnął na mydle i np. spierdolił firmware czegoś tam. Aż po ekstrema, że po prostu coś tam nie zadziałało i nigdy dobrze nie zadziała, bo nikt się nie przyzna, że/dlaczego nie działa, gdyż musiałby wymienić tysiące urządzeń albo płacić kary umowne, które by go zniszczyły; a do sądu jednak nikt nie pójdzie dla "drobiazgów", co najwyżej nigdy już nie będzie współpracował z bogu ducha winnym integratorem.

W poprzednim polskim życiu, na etacie automatyka raczej utrzymania ruchu niż projektów-integracji, oczywiście ocierałem się o pogłębiające się popier... coraz nowocześniejszych łączności elementów automatyki, w każdej nowszej maszynie i projekcie, ale były to jednak odpryski, no i powiedzmy 10 lat temu zaczynało być coraz "zabawniej", ale jeszcze daleko było do roku 2018. Chociaż jak się widziało ludzi naprawdę kumatych, starzejących się jakby tygodnie to były lata, nad projektami dla mnie, to trochę było nieswojo i czułem się z tym źle. Np. wizytujemy dostawcę trudnej maszyny, jak tam postęp, czy wszystko tiptop i w harmonogramie, bo zostało ze dwa tyg. do odbioru, a tam główny automatyk, kumaty gość, wygląda na nieco wymiętego i "przepalonego" papieroskami JESZCZE bardziej niż zwykle, "Panie X, pan wygląda na zmęczonego nad tymi naszym sterowaniem i programami... a mówiłem, to są trudne zagadnienia pomiaru i kontroli ciśnień i temperatur... - (zmęcz) panie Boni, jakie ciśnienia, jakie temperatury, widzi pan tę stertę (na biurku hałda podręczników wiodącego dostawcy niemieckiej automatyki na literę S, na oko w sumie 2000 stron) - Widzę - No, a ja to muszę chyba przeczytać jeszcze raz, bo to ich za przeproszeniem pokurwione OPC nie chce działać i nikt nie wie dlaczego, ich serwis też nie - No sorki, ale sami zechcieliście wsadzić OPC, mówiłem, że nie potrzebuję tego i wolę proste rozwiązania - Wiem. Teraz żałujemy.".

W obecnym życiu, integratora automatyki i okolic, zrobiło się od razu zabawniej. Bo komponenty i dostawcy nie są z krótkiej sensowej listy jak poprzednio, ale "nasz per klient nasz per pan", już pomijając, że w większości to są zaszłości historyczne (kto kupował masowo rozwiązania Siemensa czy Schneidera przez poprzednie 20 lat, nie przeskoczy z łatwością na Rockwella czy GE, itd), albo korporacyjne (komu globalne korpo wymusza dostawców i deal na komponenty i rozwiązania, nie ma lokalnie nic do gadania, choćby się waliło i paliło, musi się stan zawalenia i zapalenia przebić w górę na decyzyjny poziom korpo, odbić od marketingu i purchaserów "ale przecież taki dobry deal załatwiliśmy" i już 5 lat później może się coś zmieni; w wersji jeszcze zabawniejszej - zmienia go z dnia na dzień nowy właściciel korpo, czasem na dobre, czasem na zło, piekło i szatani, ale nadal: miniony w moim zasięgu mają niewiele do gadania).

Nagle okazało się to, o czym nie raz pisałem, że rozwiązania wielkich i solidnych dostawców automatyki nie kwalifikują się w ogóle do kulturalnego omawiania, tylko do obrzucenia przekleństwami i koktajlami Mołotowa. Że wyjęty z pudełka kosztowny sterownik PLC nie współpracuje z żadnym programem do jego obsługi, tylko trzeba mu najpierw spatchować firmware. Że kosztowne panele operatorskie "out of the box" są czyste jak kartka papieru i trzeba im wgrać WSZYSTKO zanim się zabierze za jakiekolwiek programowanie. Itd itp.

I to postępuje, do postępującej komplikacji coraz gorszych środowisk, pisanych w javie i podlanych pomysłami Microsoftu, dochodzi coraz większy burdel miotających się dostawców i ich developerów. Na czym spędziłem większość poprzedniego tygodnia - pozornie trywialny sprzęt, wiodącego amerykańskiego dostawcy na literę R, sterownik modułowy (PLC) z ich średniej półki, niewiele wejść wyjść, plus ich panel operatorski (HMI), też ze średniej półki. Trywialność, poza tym, że klient ma stary obiekt (bo to jest ogólnie retrofit, głównie elektryki i napędów, i przy okazji - PLC+HMI) z siecią DeviceNet, takim zabytkiem osieciowania przemysłowego sprzed zaorania wszystkiego przez Ethernet przemysłowy, więc PLC dostał moduł do komunikacji z tymże DeviceNetem.

Na dzień dobry, do zabawy z tym wszystkim potrzebne są pointegrowane w ch... środowiska i programy do developerki (posplatane ze sobą na max, bo dostawca R ma na to wyraźnie tradycyjnego zajoba od lat, żeby wszystko się zazębiało ze wszystkim), całość kosztuje bez upustów coś ponad 2000 funtów w wersji "druga od dołu, może coś się uda zaprogramować". A "pod spodem" pakietów developerskich leży znany potwór - kombajn firmy R. do komunikacji wszystkiego ze wszystkim we wszystkie strony. W założeniach, żeby było łatwiej, plug and play (prawie) i wszystko w jednym miejscu. W praktyce, działa "przeważnie", a jak nie, albo coś dziwnego jest do podłączenia, robi się "ni do rymu ni do sensu wyjmij gówno spod kredensu".

No ale za to mi płacą, żeby takie spierdoliny ogarniał, i ma się te doświadczenie z produkcjami firmy R., więc byłem dobrej myśli. Oraz komunikacja po USB do sterownika PLC zagadała "plug and play", jak powinna - aplauz i gratulacje (tu patrzymy znacząco na przykład na wiodącego francuskiego dostawcę na literę Sch., któremu jak się sterowniki USB sypnęły po wejściu win10, tak z pół roku wpierali wszystkim, że to przecież nie ich wina i "a u mnie działa"). I była to chyba jedyna rzecz w komunikacji tych 2-3 prostych pudełek, która zadziałała jak powinna...

Po dokopaniu się do modułu DeviceNet, okazało się, że programuje się go wyłącznie kolejnym pakietem firmy R. takim "do sieci" a nie "do komunikacji", cena w detalu jakieś 1100 funtów, nieplanowanych w projekcie. No dobra, zostałem wynalazcą i wynalazłem tenże pakiet, jak Iwan rower ("u Niemca na strychu"). Okazało się, że to co wynalazłem, nie czyta konfiguracji i plików od klienta (ale na to narzekaliśmy poprzednim razem) i w ogóle, tak jak pamiętałem, jest to masakryczne narzędzie. Ale powiedzmy, po krótkiej walce moduł podsieci DeviceNet zaprogramowałem, tudzież będzie czym go dopieszczać "na odbiorze".

Po dokopaniu się do konfiguracji wbudowanego w PLC Ethernetu (ma być do połączenia PLC-HMI), okazało się, że wszystkie opcje są "grayed" czyli przyblokowane, nawet podstawowe jak adres IP itp. ale nie ma w związku z tym żadnych błędów czy ostrzeżeń. Przyszło pogrzebać w grubaśnej dokumentacji, która usłużnie poinformowała, że albo PLC ma jakiś błąd (nie ma i łatwo to sprawdzić) albo ja nie mam odpowiednich uprawnień do tych operacji (no shit Sherlocku, tylko że to, czy mam czy nie mam uprawnienia i jak to sprawdzić, w trójkącie Windows - developerka - łączności, to temat na doktorat co najmniej).

Na szczęście przypomniałem sobie podobną akcję z innymi starszymi łącznościami dostawcy R. i zacząłem grzebać w kombajnie łącznościowym "pod" narzędziami developerskimi. Jak już się przebiłem przez zylion "drzew" i ich nodów, udało mi się znaleźć praktycznie te same opcje do Ethernetu, jak w pakiecie developerskim, tylko, co za niespodzianka, działające jak złoto i "panie, jakie blokady czy "grayed", tu wszystko działa". Superos, punkt odhaczony, mamy Ethernet. Wróć, mamy jeden koniec Ethernetu.

Przyszło przejść do panelu HMI, klasy 6 cali i średnia półka, takie coś jak nawigacja samochodowa sprzed dekady. Na dzień dobry panel obrzucił mnie nieprzyjaznymi konfiguracjami i ustawieniami (obligatoryjne hasła klasy jak do waszego banku przez internet, pytania pomocnicze do haseł) i całą tą nowomodna spierdoliną, jeszcze niedawno niespotykaną w byle HMI. No ale bystrze wyczaiłem, że chodzi to na WinCE z poprzedniej epoki, więc jest to HMI niepełnosprawne, a istotom ograniczonym umysłowo wiele się wybacza.

Jednakowoż, po ustawieniu wszystkiego do pionu,okazało się, że żadnej łączności ni ma. A dla ustalenia uwagi HMI ma bogato, jeden Ethernet i dwa porty USB. Po kolejnej "chwili" z dokumentacją okazało się, że port USB B jest atrapą (serio, ta budżetowa wersja HMI nie obsługuje go), a port USB A jest w zasadzie pendrive itp. jedyna "prawdziwa" opcja to ethernet. No dobra, wrzuciłem na próbę aplikację robioną wcześniej na ten HMI przez pendrajwa. Nie wstała. Gdyż developerka produkuje defaultowo appkę w wersji 10.0 a panel "out of the box" jest w wersji 9.0. Dlaczemu tak? bo ponieważ (ew. panel ze starej półki). A skądinąd firma R. uwielbia spieprzyć kompatybilność wersji hardware, software i chujware, daje do tego zylion opcji i "ułatwień", a i tak bywają fakapy, że o matko, rok temu na obiekcie mieliśmy dokładnie takie jazdy, z wersjami hard i soft różniącymi się na 2 miejscu po przecinku... Ookej, downgrade do 9.0 poproszę, appka nawet w końcu wstała, oklaski. W ramach testów, ustawiłem se wszystko z autostartem, naszym logo itp. Wydaje się, że działa. Tyle, że przestało pokazywać konfigurację panela. Oj, ja głupia nimfomanka, zachciało mi się testów.

Przyszło na serio wgłębić się w dokumentację. Okazało się, że firma R. kiedyś zapomniała, że jak się na serio serio ustawi appkę do autostartu i z blokadami operatorskimi (żeby ktoś do Win nie wyszedł) itd. w takim HMI, no to już się tego nijak nie ominie. Potem im przypomniano, że jest spierdolina (bo ludzie musieli np. rozbierać HMI, wyciągać z niego wewnętrzną pamięć w formie karty CF, znaleźć gdzieś czytnik CF, wyczyścić kartę, itp. zabawy. Przy HMI za tysiąc albo i dwa funtów.). Więc w R. dodali taki super tajny myk, że przez dwie sekundy przy bootowaniu pokazywał się biały "klawisz" w kącie ekranu, pozwalający wejść w konfigurację. Co oczywiście nasunęło kwestię, że jest spierdolina, bo na cholerę te wszystkie hasła i blokady, jak byle małpa może nacisnąć to białe i zaraz ominąć wszelkie zabezpieczenia. Więc w "mojej" aktualnej wersji, znowu nie ma żadnego wejścia w konfigurację, ale tak naprawdę jest (polecam odstawić napoje) - trzeba podłączyć zwykłą klawiaturę od PC po USB, napier... w odpowiedni klawisz przy bootowaniu, i wtedy pokazuje się z powrotem biały tajny "klawisz" konfiguracji... Zapamiętać - zabrać na uruchomienie klawiaturę USB.

Po wyczyszczeniu i ustawieniu wszystkiego w HMI z ethernetem, okazało się, że może i jest git, ale od strony programu developerskiego na moim PC nie jest. Znaczy, nie widzi on wskazanego IP, ethernetu itp. Niby było to do ominięcia, bo mógłbym przewalać zrobioną tymże programem appkę przez pendrive, ale to trochę niewygodne, i jak zwierzę. Więc zacząłem drążyć, na szczęście i fuksem względnie szybko się zorientowałem, że ktoś mnie tu robi w wała - w programie developerskim ładnie pokazano kawałek "drzewa" komunikacji i hierarchię jej nodów (do HMI trywialnie krótką), w "kombajnie" do komunikacji widać to samo; ale nagle się zorientowałem, że kiedy w "kombajnie" do komunikacji coś tam ręcznie zmieniam, np. kasuję, to w developerce nic się nie zmienia...

Okazało się, że to są dwa różne drzwka, wyglądające "tak samo", pod spodem chodzą obecnie DWA kombajny do komunikacji, stary i nowy. Developerka PLC używa obu, ale domyślnie raczej starego, a developerka HMI raczej tylko nowego... Niezmierzone są głębie mądrości firmy R.! (tutaj se można obejrzeć eksponaty, czyli trzy programy, których potrzebuję, żeby ogarnąć żałośnie prosty projekt...)

I to by było na tyle. I nie było to BARDZO zło i szatani, o, daleko do tego - nic tu nie chodziło przez chmurę (jak u wiodącego dostawcy G.), nie miało spier... firmware (jak w paru przypadkach ostatnimi laty), nie wymagało patchowania "na dzień dobry", prawą nogą przez lewe ramię (jak u wielu). Raczej był to standard.

Morałów jest kilka, poza "70% pier...my się z komunikacją, 15% z klientem, 5% z dokumentacją, na programowanie mamy pozostałe 10%".

Np. jeszcze 15 lat temu uważano, i sam lansowałem tezę, że dobry fachowiec to taki, który zna się na automatyce, różnych PLC, SCADA, HMI itp. i na procesach przemysłowych, a właściwej deweloperki konkretnego dostawcy nauczy się w locie. No więc obecnie nie nauczy się w locie, bo jest to nauka jazdy po polu minowym, i dla w miarę kompletnej oferty takiej przykładowej firmy R. (czy podobnych) nawet doświadczony ogólnie gość, ale niedoświadczony z AKTUALNYMI fakapami firmy R., na oko potrzebowałby miesięcy i paru projektów. Więc możliwe są bardzo malownicze frustracji i porażki.

Inny morał jest taki, że wszystkie te łączności są znacznie gorsze niż też UPIERDLIWE (ale inaczej) łączności z poprzedniej epoki i po 20 latach obiecanek "plug and play", otwartych rozwiązań, przyjaznej kompatybilności, itd. wiodący dostawcy nawet nie są w pobliżu rozwiązań i dobrej praktyki DOBRYCH dostawców sprzed 15 lat. Co smutne i frustrujące.

Ale rewolucji nie będzie, to nie są miliony sfrustrowanych klientów, którzy pójdą gdzieś indziej. To nie smartfon, że jak ci się krzaczy, jest niekompatybilny z czymkolwiek, wifi się wiesza, itd. to kupisz inny od innego dostawcy. Tu nie ma tak łatwo i tanio, a i o lepszych dostawców coraz trudniej.




Wpisz dane i komentarz:

Autor:

Hasło:

albo CAPTCHA dla niezarejestrowanych:

Druga planeta Układu Słonecznego:

Treść:

Formatowanie: [b] pogrubienie [/b], [i] kursywa [/i], [u]podkreślenie[/u], link: URL lub [a="URL"]tekst[/a], nie używać nawiasów {} i tagów HTML. Max długość ok. 3000 znaków.


cmos
Mon, 20 Aug 2018 12:21:44
@boni
U mnie jest podobnie. Moim zdaniem bierze się to stąd, że branże specjalistyczne - jak Twoja automatyka albo moje automotive - w szybkim tempie przemieszczają się od elektromechaniki w stronę full blown informatyki, a ludzie którzy to robią to ciągle automatycy, elektronicy czy podobni, co najwyżej po kursach programowania. No i oni po prostu nie są w stanie tego porządnie ogarnąć.

Z drugiej strony naprawdę trudno o dobrego informatyka, który po obejrzeniu tej specjalistycznej problematyki nie ucieknie z krzykiem. Jeżeli w ogóle zostanie zaangażowany, bo w HR przecież usłyszy "no ale pan nie zna naszej branży".

Z trzeciej strony to jest jednak szansa dla tych paru osób na świecie, które dobrze znają się i na informatyce, i na danej branży. Wiadomo, trudno w ten rynek wskoczyć, ale technicznie zrobienie czegoś porządniejszego to żaden problem.

charliebravo
Mon, 20 Aug 2018 13:07:06
@cmos
No, ale informatyka ma jeszcze tą cholerną chorobę "że musi być najnowsze". Boni narzeka na Javę z czymśtam i słusznie, ale przecież za chwilę "wjadą" tam Javascripty i to będzie dopiero rozwałka.

Nb. w firemce dla której pracuję planowano zrobienie nowego urządzenia w oparciu o nową architekturę mobilną Intela. No bo do tej pory używaliśmy i.mx6 (skądinąd ponoć popularnego w kręgach automotive?), ale oczywiście klienci i szefostwo chciało lepiej-dalej-więcej-szybciej, więc ten Intel, bo Intel "jest mocny". O tym jakie mózgi tam pracowały, najlepiej świadczy timeline wdrożenia nowego urządzenia: były tam miesiące na iteracje obudów i płytek drukowanych, ale już taki "drobiażdżek" jak port softu (bagatela pareset tysięcy linii, w tym używanie hardware'owych dekoderów multimediów) - nie, bo przecież po co.

DYGRESJA: kolejnym problemem jest to, że przecież "każdy facet zna się na komputerach". Więc jeśli gość jest designerem, albo managerem, albo czymkolwiek, ale umie zainstalować windowsa i wybrać aparat z największą ilością megapikseli, to oczywiście czuje się "na siłach" wybrać nowy SoC, bo czemu nie: jak najwięcej gigaherców za jak najtaniej...
/DYGRESJA.

Żeby było jeszcze śmieszniej, 30 programistów w tym z dziesięciu niskopoziomowych pracuje piętro niżej od kolesia, i ogólnie wystarczyłoby spytać, a nawet jak nie pytał, podnieśliśmy wrzask - co nic nie dało, bo przecież "Intel is the best, and we want best".

Szczęśliwie w międzyczasie zdarzyły się dwie rzeczy - Intel wycofał się z produkcji części chipów, czym zrobił dużą krzywdę kilku firmom ze dwa rzędy wielkości lepszym niż nasz pracodawca, oraz części do pierwszej generacji urządzenia zrobiły się nie do kupienia, co wymusiło paniczny upgrade na tym samym i.mx6, ale wyższy model, lepszy chip do sieci, GPU, więcej RAMu, szersze szyny...

...no więc właśnie bawię się modelem przedprodukcyjnym, na którym stary soft poszedł po cross-compilacji od razu (!), i niemal wszystko działa (!!), w tym hiperupierdliwy chip do dekodowania H264 (!!!). Nawet ponoć szefowie trochę zmądrzeli, i zaczynają przebąkiwać o użyciu i.mx8 w następnej iteracji...

Ale tendencje są jakie są, więc podejrzewam że (dla mnie) przywilej obserwowania tego z komfortowej dziury pod kamieniem nie będzie trwał wiecznie. W międzyczasie - współczuję.

Boni avatar Boni
Mon, 20 Aug 2018 14:03:12
IMHO to co cmos często podnosi, to w mojej branży było gdzieś tak do 2005, powiedzmy do epoki winXP: miało się wrażenie, że to elektronicy i elektrycy przyuczeni do IT, wychowani na RS232/485 i ledwo ogarniający eternety, próbują dogonić świat Windowsa i osieciowania. Potem (i nadal) wahadło bujnęło się, żeby nie powiedzieć, jebnęło w drugą stronę, i mam wrażenie, że te łączności, developerki itd. robią teraz całkiem "czyści" informatycy, którzy dla odmiany nigdy nie widzieli na oczy automatyki przemysłowej, nie programowali tą developerką swojej produkcji żadnego HMI czy PLC "out of the box", nie spróbowali eksportu/importu jakiegoś prawdziwego średnio skomplikowanego projektu, nie próbowali postawiać SCADA z licencją w chmurze, w środku lasu, gdzie nawet jakby była jakaś sieć, to nikt by do niej się nie odważył podpiąć obiektu typu "jak ktoś wyhaczy, to 100tys ludzi nie ma wody abo prądu", itd itp. I zapewne na biureczku i w maszynach wirtualnych im to wszystko działa, a na porządne testowanie tego nikt pieniądza nie ma. No dobra, prawie działa, skoro pierwszy duży patch świeżej SCADA czy developerki miewa changelog na 1200 pozycji (i to w stylu "200 fakapów, 600 major, 400 minor, plus wishlista "na potem", na kolejne 600 pozycji"), więc DKJP.

A propos "miejsca dla kumatych ludzi", akurat jak se pływałem tydzień w tym płytkim szambie, akuratnie przyszło info, że Rockwell Automation (Edynburg) szuka kogoś na Project Managera. Jakbym miał czas i nudził się, to bym spróbował się przebić przynajmniej do interview, żeby spotkać tych uroczych ludzi i dowiedzieć się, komu wysłać kwiatki za te kwiatki, ew. komu dać w kły. Ale aż tak się nie nudzę i wisi mi to, płacą mi za bujanie się w szambie, to się bujam, jak wszyscy w koło.

cmos
Mon, 20 Aug 2018 14:09:43
@charliebravo
@Intel
To wyraźnie całkiem inny segment, u nas nic Intela nie ma i nikomu nawet do głowy nie przyjdzie szukać w tym kierunku.

@wybór procesora
W poprzednim projekcie klient na B przyszedł i zarządził, że robimy na takim nowym procesorze, trzy core ARM based i kupa innego sprzętu, świetny jest, znaczy eee będzie za trzy miesiące, na razie zaczniecie na tymczasowym wariancie polutowanym z kilku chipów na płytce.
Procesor oczywiście był nie za trzy miesiące, tylko za sześć, było z nim masa problemów, a sam producent (w zasadzie to takie firmy to nie producenci, tylko integratorzy zakupionych modułów) nie był w stanie wyjaśnić do czego służą niektóre bity w konfiguracji ochrony pamięci.



cmos
Mon, 20 Aug 2018 14:42:08
@boni & kadry
Wyraźnie jesteście już trochę dalej, co nie znaczy że w lepszej sytuacji.

@miejsce dla kumatych ludzi
Pływanie w szambie i rozpoznawanie fackupów bojem trochę mi się już znudziło, więc ostatnio robię zakusy w innym kierunku - zamierzam puścić własne narzędzie, jakiego na rynku brak. Rzecz jest na tyle prosta, że po kilku tygodniach mam już większą część pierwszej wersji, a już są tam rzeczy jakich nikt dotąd nie zrobił. Zobaczymy co z tego będzie.

charliebravo
Mon, 20 Aug 2018 15:03:44
@Boni
No, ja się "trochę" zdziwiłem jak zobaczyłem OPC - słabo się znam na automatyce ale to był początek szaleństwa. Za żadne skarby nie potrafię do tego wymyślić innego uzasadnienia niż "interes Microsoftu", który zresztą był i tak zapewniony bo przecież i wtedy i teraz (chyba że się zmieniło) dowolny PC w automatyce przemysłowej chodzi na jakichś Windowsach.

OK, w teorii jednym (słabym raczej) plusikiem byłaby możliwość autodetekcji tego co jest na urządzeniu, zamiast pracowitego wklepywania tagów i numerków portów (jak dla Modbusa). Co zresztą można by rozwiązać bez ruszania protokołu (ów), na przykład przyjąć jeden format plików opisujących możliwości urządzeń Modbusowych, i taki format mogłaby sobie wczytywać każda SCADA i automatycznie tworzyć tagi czy co tam trzeba.

He he, wyobrażam sobie spotkanie automatyka z frontu z Rockwellem, trochę w stylu "I'll tell you something about my mother" :-)

@cmos

No robienie czegokolwiek na Intelu nawet dla tak zielonego w elektronice człowieka jak ja wygląda na idiotyczne. Na przykład i z tego co pamiętam żeby zasilić ARMa dostarczasz jedną linią jedno napięcie i natężenie, i tyle. Do tego, żeby ruszył Intel trzeba coś ze czterech, i ze ścisłymi tolerancjami. To pewnie nie problem jak się robi laptopa w milionach egzemplarzy, ale jak mała firma robi maleńkie urządzenie do sprzedaży w może 100 tysiącach sztuk (jak dobrze pójdzie)...

"zamierzam puścić własne narzędzie, jakiego na rynku brak"
Brzmi interesująco. Ja mam taki projekt, w który wrzuciłem dwa lata ale pieniądze mi się skończyły a robota nie chciała, więc poszedłem robić tu gdzie robię. Ale coraz częściej to do mnie "wraca"...

cmos
Mon, 20 Aug 2018 15:54:26
@charliebravo
"Ja mam taki projekt, w który wrzuciłem dwa lata ale pieniądze mi się skończyły a robota nie chciała"

U mnie to poza czasem jest prawie bezkosztowe (250$ za jeden taki program, nawet Visual Studio jest teraz legalnie free jako Community Edition). Ale jak już dojdzie co do czego, to będę musiał położyć 10k EUR za członkostwo w konsorcjum, znaczy żeby właściwe logo mieć.


Codiac
Mon, 20 Aug 2018 20:38:31
"To nie smartfon, że jak ci się krzaczy, jest niekompatybilny z czymkolwiek, wifi się wiesza, itd. to kupisz inny od innego dostawcy."

Żeby to było takie proste, ale na tym rynku też jest przecież spierdolina. Bo co z tego, że pójdziesz do innego dostawcy jak dostaniesz taki sam szajs na androidzie, bo wszyscy robią teraz na androidzie i wszyscy lecą w "dajmy jak największy ekran!" do tego stopnia, że niektórych telefonów nie da się trzymać w jednej dłoni? Jedynym wyjątkiem jest Apple, które nadal ma swój standard i OS i się go trzyma. Więc twój wybór sprowadza się do "iphone czy android a jeśli android to od którego dostawcy i ile chcesz wydać".
Jak ja się cieszę, że zdążyłem kupić telefon z Windows Phone, który może rewelacyjny nie jest, ale przynajmniej interfejs ma dla mnie wygodniejszy, a setki aplikacji i tak nie potrzebuję. Ale też mam smutną refleksję, że jak mi padnie to albo przepłacam za iphone (za którym zresztą nie przepadam) albo idę się męczyć z androidem, którego nie cierpię znacząco.

Boni avatar Boni
Mon, 20 Aug 2018 22:05:50
@cmos
Procesor oczywiście był nie za trzy miesiące, tylko za sześć, było z nim masa problemów, a sam producent (w zasadzie to takie firmy to nie producenci, tylko integratorzy zakupionych modułów) nie był w stanie wyjaśnić do czego służą niektóre bity w konfiguracji ochrony pamięci.

Cudo. A ja przecież dłubię o oczko wyżej, tj. ktoś kto dłubał ten PLC czy HMI ze dwa lata temu być może właśnie takie rzeczy mógłby opowiedzieć. Potem na to nałożyli sk... firmware, szczególniej komunikacyjny, potem niechlujną developerkę pod sk... Windows, a potem jestem ja, dłubiący na chybcika gównianie rozwiązania, a potem ktoś będzie się z tym bujał dekadę. Welcome to the desert of the real.

@charliebravo

Tak, wszystko jest uwikłane w Win i świetne pomysły M$ (np. DCOM, DCOM wszędzie), także te z przyszłego miesiąca. Tak, OPC miał być otwartym standardem, żeby skończyć ze spierdoliną wiecznie nieaktualnych i porąbanych driverów do Win, ale oczywiście w praktyce dodał tylko dodatkowy poziom driverów (bo zamiast driverów do Win są "drivery do OPC") i spierdoliny, plus miał nieprzemyślane mnóstwo rzeczy od początku, właśnie wyglądał jak w tezach cmosa, "jak po koniec '90 automatycy bez większego pojęcia o systemach i IT wyobrażali sobie fajny protokół i platformy".

@jeden format, unifikacje, itd.

W kontekście powyższego - tak naprawdę nikt nie jest zainteresowany prawdziwą unifikacją, tylko "wiodący dostawcy" liczą na utrzymanie swojego kawałka tortu, ew. zaoranie konkurencji. OPC itp. zostało "wymuszone" przez wpadnięcie wszystkich pod but M$, czyli w OLE, COM, potem DCOM. Ale z dużych graczy nikt palcem nie kiwnie, żeby integrować się między sobą, a nie tylko z M$; a mali nie mają ani zasięgu, ani zasobów, żeby coś konkurencyjnego zaoferować w temacie SCADA itp., a na poziomie PLC, HMI, napędów itp. wszystko jest za bardzo uwikłane w proprietarny hardware "wiodących dostawców". Bo to już nie są dawne czasy, kiedy ktoś ujawniał wewnętrzne protokoły czy architektury, ułatwiając robienie third party appek, teraz raczej urwą ci głowę razem z torbą za reverse engineering, jeśli spróbujesz zrobić narzędzia do ICH hardware bez ICH imprimatur.

@Codiac

True, ale nadal w electro i IT konsumenckiej jest 10x łatwiej, i duża konkurencja IMHO nadal powoduje jakieś tam doskonalenie (sprawdzić czy nie Google). W automatyce jakoś nie zauważam doskonalenia, raczej: duża konkurencja powoduje paniczne pogonie za wodotryskami (zbędnymi) i najnajnaj- rozwiązaniami (niezbyt działającymi), jw. dyskutowano. Czyli, być może, należałoby obwiniać wyłącznie ignorancję klientów... czemu nie.

cmos
Tue, 21 Aug 2018 12:00:10
@boni
"a potem ktoś będzie się z tym bujał dekadę

U nas nas szczęście czas życia rozwiązań jest o wiele krótszy - projekt, potem ze dwa lata drobnych zmian dla model years, a potem i tak przychodzi nowa generacja, na innym sprzęcie i z innymi koncepcjami.

@unifikacje
I to u nas jest inaczej - ponieważ jeden klient zamawia dużo kawałków u różnych firm do jednego samochodu (do tego, do którego robię kawałków jest 60!), to bez unifikacji nikt nie byłby w stanie tego ogarnąć. A znowu każdy poddostawca robi dla różnych klientów i wszystkim jest taniej jak robić według jednego standardu. No i unifikacja nawet się posuwa, coraz więcej klientów wchodzi w ten AUTOSAR. Tylko porządnego narzędzia żeby robić design w modelu ciągle brakuje (i wtedy wchodzę ja, cały na biało... :-) ).

A różnica chyba jest w tym, kto zamawia: U nas zamawia klient, i na jego zamówienie się robi. U was dostawcy robią według własnych idei, a klienci muszą wybierać z tego, co jest.

charliebravo
Tue, 21 Aug 2018 12:35:41
@cmos
"U nas nas szczęście czas życia rozwiązań jest o wiele krótszy - projekt, potem ze dwa lata drobnych zmian dla model years, a potem i tak przychodzi nowa generacja, na innym sprzęcie i z innymi koncepcjami. "
A czy to jest "na szczęście", to ja bym chyba polemizował. No bo dostajesz taki "nowy procesor co świetny jest" (a w praktyce pewnie bardziej SoC niż procesor), i wszystkomający (GPU do grafiki, VPU do (de)kompresji video, IPU do akceleracji obróbki obrazu, CPU do rządzenia tym wszystkim, sieci, HDMI, interfejsy do wszystkiego). I jak masz szczęście, to do tego jest dokumentacja i przykłady, znaczy na poziomie "jak zdekodować h264" albo "jak wyświetlić obrazek", albo "jak postawić Linuxa". I OK, każdy _z osobna_ działa.

Ale zrobienie z tego zintegrowanego i dobrze działającego systemu, tzn. nie że każdy podsystem z osobna, tylko wszystko działa _razem i spójnie_, na przykład pakiety przychodzą przez sieć, VPU dekoduje, GPU wyświetla, dźwięk idzie przez HDMI i jest zsynchronizowany z video, a wszystko powiedzmy Full HD@30Hz, i nie ma przecieków pamięci, i się nie przegrzewa, nie resetuje co parę godzin, i nie zżera pamięci, i nie wiesza się z tajemniczych przyczyn u 20% klientów - to zabiera lata.

Jak przyszedłem do obecnej pracy to produkt miał ze dwa lata, i to niby nawet działało i na ogół nie było dramatu, ale kod od multimediów wyglądał tak, że co się na niego patrzyłem to się płakać chciało, bo to było tak: jakiś elektronik od lutowania chipów na Tajwanie "nauczył się" a tak naprawdę skopiował dość OpenGLa żeby ramki się pokazywały, i odfajkował. Potem jakiś programista poskładał dwa-trzy przykłady metodą copy and paste i tak długo zmieniał losowo kluczowe elementy aż się coś pokazało. Ze trzy tysiące linii a w OpenGLu naprawdę można zrobić piękny spaghetti code! To już byłoby wystarczająco złe i normalnie, ale potem dołożono bibliotekę open source do dekodowania multimediów. Nikt nie wiedział, że bibliotekę napisał jakiś szaleniec/idiota i właściwie należałoby go rozstrzelać za sabotaż, bo był to "generator losowych zwisów". Do tego wszystko chodziło na letko przypadkowej dystrybucji Linuxa, z driverami do GPU chyba z poprzedniej dekady, z błędami w kluczowych funkcjach (np. glClear nie można użyć, bo się wszystko wali).

Teraz już wszystko jest spoko, ale to dlatego że przez ponad rok przepisałem właściwie 100% powyższego (no dobra, z driverem po prostu nauczyłem się żyć). A przecież u nas to jest pod wieloma względami prostsze niż w samochodzie, bo mamy jedno urządzenie embedded, kilka programów klienckich na Windowsy/Maca/takie tam i to wszystko.

Zmierzam do tego, że jak cykl życia ma dwa lata, to nie ma żadnych szans na to, żeby ktoś przyszedł i przepisał sensownie. A od pierwszego podejścia nawet bardzo dobry fachowiec może nie zrobić "dobrze", bo jak zaczyna się robić taki system to zwykle nie wie się gdzie będą problemy. Oczywiście może spieprzyć mniej, może przygotować bardziej stabilną architekturę, no ale wszystkiego nie przewidzi.

"w automatyce dostawcy robią według własnych idei"
Nooo...czasem tak, ale czasem zupełnie nie. Przecież znowu - każdy facet zna się na elektronice, więc takich zamówień że masz coś dodać do systemu ale koniecznie przy użyciu produktu X, też bywa dużo.

@Google i doskonalenie
He he, jakiś czas temu (miesiąc) przez sieć przetoczyło się insider info z "Project Fuchsia" (to jest Googlowy wewnętrzny projekt, który buduje następcę Androida). Historia szła jakoś tak, że inżynierowie zaprojektowali fajny kawałek systemu operacyjnego z porządną ochroną prywatności, na co wpadli z awanturą sprzedawcy reklam, że jaktotak, przecież musimy sobie zaciągać dane o użytkowniku. Zgadnijcie, kto wygrał?

cmos
Tue, 21 Aug 2018 13:13:42
@charliebravo

No jednak, o ile kodowanie u nas też jest katastrofalne, to klienci nie tolerują zwisów. Żadnych. Nawet jak system się po nich podnosi bez problemu. Więc robi się tak długo, aż zwisów nie ma.

"Nooo...czasem tak, ale czasem zupełnie nie"

Czasem... U nas nie ma czasem, wszystko jest na zamówienie. Właśnie Intel próbował kiedyś zrobić platformę sprzętową z półki, ale to nie da rady. Chociażby dlatego, że przy skali na setki tysięcy albo miliony sztuk, specjalny sprzęt przykrojony do potrzeb na pewno wyjdzie taniej niż standardowy.


mgr Sianko
Thu, 23 Aug 2018 10:55:51
A myślałem, że tylko w projektach bankowych jest taki burdel. Niedługo zacznę się bać samochodu i telewizora...
Jak działa QA w branży automotive czy embedded? Czy testy też projektują tylko elektronicy?


cmos
Thu, 23 Aug 2018 11:45:54
@mgr Sianko
"Jak działa QA w branży automotive czy embedded?"

W automotive działa to o tyle nie najgorzej, że zawsze podstawą są dokładne requirementy klienta. Tracing tych requirementów robi się przez cały proces, aż do testów. Na każdy requirement musi być chociaż jeden test w teście systemu.
Te testy systemu robi się w większości ręcznie, ale się naprawdę robi. I nie ma większego znaczenia jakie wykształcenie ma ich autor. A potem testy robi też klient, też według tych requirementów, i to często nawet dokładniej.

Zupełnie inną sprawą są testy modułów, tu nie jest wesoło - u nas nie ma nawet przyjętej jakiejś standardowej platformy i metodologii. Każdy developer ma zrobić specyfikację testów swojego modułu, ale to najczęściej przesuwa się na ostatnie dni przed SOP, albo nawet na po SOP, a to wtedy i tak musztarda po obiedzie. No i te testy są zazwyczaj po linii najmniejszego oporu - czyli ręczne, a to znaczy że nie są robione po każdej modyfikacji, tylko jak trzeba protokoły skompletować.

"Niedługo zacznę się bać samochodu i telewizora..."
Telewizor LCD jeszcze nikogo nie zabił. Natomiast u nas są tacy, co mówią że nie kupią żadnego samochodu, o którym wiedzą jak był robiony. A ponieważ u nas robi się do większości marek, to muszą unikać kontaktów z innymi działami, żeby mieć w ogóle coś do wyboru.

Ale ja bym nie przesadzał. Z mechaniką nie jest tak źle jak z softem, a zasady safety jako tako protezują marny soft. Kiedyś tych ASIL-i nie było wcale, a samochody jeździły i nie zabijały wszystkich dookoła.

Boni avatar Boni
Thu, 23 Aug 2018 14:47:26
@cmos

Natomiast u nas są tacy, co mówią że nie kupią żadnego samochodu, o którym wiedzą jak był robiony

BTW w tym sensie dochodzę pomału "do ściany" na szrocie, bo już lexus GS następnej generacji byłby cały w CANbusach itd. nawet chyba polift tego co mamy około 2003 już ma pewne zaszłości, których wolałbym na szrocie uniknąć... A lexusy i tak są konserwatywne jak jasny gwint w porównaniu z "niemcami", jakieś 5 lat w tyle minimum.

@testowanie

W embedded OIMW testuje się jak wszędzie, wujowo. A u mnie w automatyce przemysłowej jeszcze gorzej, w zasadzie zależnie wyłącznie od tego, kto akurat dłubie i dla kogo ten wywiad. Inna sprawa, że są to rzeczy ZNACZNIE znacznie prostsze i bardziej zdeterminowane niż embedded czy automotive, znaczy, obecne ich wersje.

cmos
Thu, 23 Aug 2018 15:40:50
@Boni
"W embedded OIMW testuje się jak wszędzie, wujowo.

W automotive jest o ten włos lepiej, bo jak samochód z przyczyn softwarowych zabije jakiegoś użytkownika, to odszkodowania, koszty recalli itp. będą liczone w grubych milionach. Stąd trzeba mieć jak najlepsze podkładki w postaci specyfikacji testowych i protokołów testów z przynajmniej teoretycznym wykazaniem kompletności testów.

W automatyce przemysłowej jak sterowanie kogoś nawet zabije, to ten ktoś podpisał że był przeszkolony na BHP i jest sam sobie winien (nieco upraszczając oczywiście), więc porządniejsze testowanie się nie opłaca.

A w consumer electronics to już w ogóle, TV czy telefon nie dadzą rady nikogo zabić.

Boni avatar Boni
Fri, 24 Aug 2018 00:35:25
@komputery a zabijanie

No z automatyką przemysłową jest ten drobny problem, że teoretycznie spierdolina na jakimś PLC czy łącznościach itp. może wygenerować drugi Bhopal czy Czernobyl or compatible, a nie tylko urwać łapę pracownikowi i przecież jego wina, bo hełmu nie miał. Albo wygenerować znaczne koszta przy przestojach i wyłączeniach, co kosztowniejszych procesów czy infrastruktury dla 100tys ludzi. Więc przy ryzykowniejszych aplikacjach jw. jednak się specyfikuje i testuje trochę, aż po SILe itd. Ale w praktyce spierdoliny w projektach i w elektryce/mechanice/hydraulice/etc (analogia automoto: i co z tego że satnav się krzaczy, jeśli wałki rozrządu trzeba wymieniać co 30tys km), oraz w procesach i utrzymaniu ruchu tychże aplikacji (co z tego, że satnav się krzaczy, jeśli wina kierowcy, że wjechał w morze, albo mechanika, że koło odpadło), nadal są na oko jakieś 10x bardziej prawdopodobne, więc luzik.

Fakt, consumer i ew. embedded w consumer to jest dno pod mułem, bo jak się komuś TV czy telefon zwiesza czy ogólnie pier... nie robi, to tylko frustracje, ew. pójdzie po drugi, do konkurencji czy "konkurencji", nie jest to choćby w pobliżu ryzyka jak automoto (ogólnie transport) czy automatyki (tej ryzykowniejszej części), stąd wydaje się, że podejście w consumer jest "a na cholerę przepłacać za projekty i testy".

cmos
Fri, 24 Aug 2018 12:38:38
@boni i consumer

Po moim telewizorze to widzę że oni tam nie tylko nie testują, ale nawet żadnych założeń projektowych nie mają. Telewizor po każdym updacie zachowuje się inaczej i to czasem na poziomie całkiem podstawowych koncepcji (typu: czy przy przejściu ze standby do running zapalamy diody, czy nie - był okres że się nie zapalały, potem że tak, potem znowu nie, teraz znowu tak...). Był okres że telewizor się resetował w trakcie standbaju, w nocy, przy inicjalizacji włączając dźwięk i nie reagując przez kilkanaście sekund na pilota. Po prostu co kto wymyśli, to zmieni w programie, a potem przychodzi ktoś inny i zmieni inaczej. A kogo to w ogóle obchodzi, jakiś soft, to tylko złośliwa narośl na sprzęcie.

red.grzeg
Fri, 24 Aug 2018 14:41:37
Chętnie bym zobaczył gradację, gdzie jest najlepiej, najgorzej.

W mojej działce IT, to w poprzednim miejscu komponenty związane z płatnościami były dość solidnie pisane i testowane.

Boni avatar Boni
Fri, 24 Aug 2018 16:13:23
@gradacja i porównania

Tia, byłoby fajnie, ale jak to zrobić, to nie wyobrażam sobie. Znaczy, anecdata i anekdotami możemy się przerzucać i to robimy, ale w miarę rzetelne porównania, niby jak.

BTW właśnie siedzę i sprawdzam szefa wypociny do projektu na SIL2 i jest tak, że główne zagadnienie to nie programy itp. tylko jak nauczyć klienta, że za ich własne spierdoliny odpowiadają oni, i nikt inny, i to tak, żeby się nie obrazili. Oraz jak ująć w papierach i obłożyć się dupochronami, że z 3 funkcji bezp. w projekcie 1 jest spoko na SIL2, 2 jest około SIL1.5 i jak zmrużyć oczy (czytaj - dołożyć udokumentowanych testów i maintenance) powiedzmy naciągnie się do SIL2, ale funkcja 3 na pewno jest krytykiem i powinna być pod SIL2, ale nikt nie wie, nie panuje, nie ma pojęcia co i jak, i dostajemy z tej funkcji do naszego systemu zwykły sygnał "okej - nieokej" zwykłym przekaźnikiem. A od tego sygnału naprawdę zależy, czy to wszystko będzie działało bezpiecznie przez lata, czy któregoś dnia kawał spec-filtra spali się jak spora bomba termitowa (można guglać albo jutubić pod "titanium powder fire"). Oby nie razem z całą fabryką. I wiadomo to od paru miesięcy, że ten kawałek nie da się w obecnej formie naciągnąć do SIL2 choćby nie wiem co.

Czy ktoś postuluje wyłącznie filtrów jw. chodzących tu i ówdzie? albo przerobienie tego, co tydzień temu uruchomiono? ależ wodzu, co wódz.

Fri, 24 Aug 2018 21:42:41
A to właśnie Jubal zapodał coś w temacie Tesli. Akurat pasuje.

charliebravo
Fri, 24 Aug 2018 22:41:44
@Zawieszanie się consumer embedded
No, to prawda, u nas się może wieszać. Nie mam tylko pomysłu jak zrobić coś co działa po WiFi i HDMI “niewieszajacym”. Mamy statystyki I automatyczne raportowanie, WiFi to problem numer jeden (a my pchamy tam Full HD video). Potem długo, długo nic, i dopiero inne.

Wiec jak wymieniłem dekoder video na przyzwoity, to w statystykach widać „schodek”, ale nie żeby rewolucja.
Ja zreszta staram się powoli pchać, żeby to bulo porządnie, ale to trwa. Testy komponentów mamy, niektóre spoko, ale tak czy inaczej wszystko się rozbija on tą cholerną sieć.

@Tesla
Poczytalem i rzuciłem się z wrzaskiem do ucieczki. Naprawdę nie rozumiem czemu IT przeszło od czegoś aspirującego do inżynierii do...nie wiem...tego koszmarnego LEPIENIA wszystkiego z g...

Tzn wiem, ale smutno...

Boni avatar Boni
Fri, 24 Aug 2018 23:49:43
Zanim jeszcze Aniou podrzucił wieści z Tesli, miałem popołudniową akcję: zamknąłem lapka w pracy (średni dell na win10), a po otwarciu w domu wypierdolił się do góry kołami do BSOD niczym win98 czy inna Vista. Co zdarza mu się raz na miesiąc-półtora. Zamiast szacować szkody (bo trochę tam mogło polecieć w pizdu, np. VM jedna czy druga), zachciało mi się tym razem wgłębiać w logi i takie tam, żeby może ustalić, co się popieprzyło.

No więc jak już przyjrzałem się logom, to powstała kwestia nie "czemu to się wypierdala raz na miesiąc" ale "JAKIM CUDEM TO W OGÓLE DZIAŁA NA CO DZIEŃ??!!". Zanim cokolwiek ustaliłem co do kraszu, ustaliłem że sam Event Viewer też się nieco pierdoli, więc żeby nie jebnąć lapkiem o ścianę, odłożyłem win10 na bok, a szacowanie szkód na poniedziałek, kiedy zapłaci za te godziny pracodawca, i oddałem się innym ćwiczeniom, jak np. "który złom jest najstarszy w chałupie i czy wstanie?" (wstał, malutki IBM 240X z winXP, od lat nieużywany; ori 2000r z win98SE), wszystko to żeby uczcić dzisiejsze Święto Windowsa (podobno się obchodzi).

A po tym wszystkim, to już ja byłem po drugiej stronie wkurwu i zen-wyjebany i mnie żaden Musk czy inna pierd... Tesla nie interesuje, ogólniej temat "dlaczego nie każda inżynieria da się sprowadzić do devopu skończoną ilością praktykantów" obchodzi mnie przyzerowo. Dopóki nie przybędzie mi zainteresowania, z mojej strony nie będzie więcej o tym notek, rozważań, zachwytów czy narzekań.

Niech spłoną. Ja na swoją bańkę benzyny i tak zarobię.

cmos
Sat, 25 Aug 2018 09:26:02
Przeczytałem to o Tesli, i jest dokładnie tak, jak się spodziewałem i jak cały czas twierdzę. Ja też robię w infotainmencie, więc mogę porównać. Oni robią jak na peceta, a nie jak robią soft normalne firmy samochodowe (przynajmniej te, dla których robiłem projekty). Żaden normalny producent nie zaakceptuje godzinnego flashowania wszystkiego na linii - na linii robi się tylko EOL, znaczy przede wszystkim coding i wgrywanie kluczy. Inaczej opory powietrza są za duże :-) We wszelkich zasadach jest wyłączanie tracingu w wersji do produkcji - tak niedojrzałego softu jak u Tesli nikt by nie wgrał do samochodu idącego do klienta. A tu logi na terabajty. Flashowania bezprzewodowego nie ma w żadnym z projektów z którymi się stykam, nie bez przyczyny. Niecertyfikowalny embedded Linux nawet w infotainmencie jest rzadko i tylko jak nie robi nic co jest safety related (są systemy pochodne od *ix-ów ale certyfikowane, jak potrzeba). A w tych tekstach co i raz coś wyraźnie związanego z Linuxem. I tak dalej, i tak dalej.

W sumie: Nawet soft do "normalnych" samochodów to spierdolina, ale na tamto to mi nawet określeń brakuje.





Engine: Anvil 0.88   BS 2012-2018