Odpowiedzialność w systemach krytycznych

Cześć.mam pytanie odnośnie odpowiedzialności programisty embedded przy systemach krytycznych. Wiadomo, że nikt nie jest nieomylny, ale co jeśli developer przez przypadek, z pośpiechu, zmęczenia itd. popełni błąd który w przyszłości może skutkować awarią w sofcie np. jakiegoś elementu kluczowego dla bezpieczeństwa w automotive lub przy urządzeniu medycznym itp. Jaką odpowiedzialność ponosi programista który taki błąd popełnił lub zatwierdził czyjeś zmiany z bugiem, a coś przeoczył?
Warto się pchać w takie działki, czy lepiej odpuścić i poszukać czegoś mniej "odpowiedzialnego" np. w webie?
Czy ktoś z Was pracuje przy takich systemach i mógłby odnieść się do tematu?

slyszalam ze w tego typu programach stosuje sie "weryfikacje formalna" https://en.wikipedia.org/wiki/Formal_verification#Approaches

Między innymi po to w Automotive szeroko stosuję się MISRĘ C, a kod waliduje Ci inna osoba z zespołu[pomijając ile tego kodu generuje za Ciebie AUTOSAR], żeby takie sytuacje nie miały miejsca.
Potem całość przechodzi jeszcze przez szereg innych osób związanych za sprawdzanie tego wszystkiego, więc raczej nie ma tu mowy o jakichś wielkich odpowiedzialnościach.

Kiedyś zapytałem kolegi, czy nie boi się, że kiedyś przeczyta o awarii samochodu, do którego tworzył soft - odpowiedział, że nie bo nie czyta takich artykułów.

E: Natomiast samej pracy nie polecam.

Co do zasady, wiele zależy od sposobu, w jaki ten programista jest zatrudniony:

• jeśli jest to umowa o pracę, to pracownik odpowiada za błędy nieumyślne do maksymalnie trzykrotności swojego miesięcznego wynagrodzenia
• w przypadku UoP limit trzykrotności nie ma zastosowania, jeśli szkody powstały w wyniku celowego działania. Ważna uwaga - rażące zaniedbania oraz mocne nagięcie "zasad sztuki" często może być traktowane jako działanie umyślne
• w przypadku B2B - wszystko zależy od tego, jak została umowa skonstruowana. Teoretycznie jest możliwość obciążenia programisty wszelkimi poniesionymi szkodami, co w przypadku osoby prowadzącej działalność gospodarczą może oznaczać także np. wjazd komornika na chatę i inne cenne rzeczy. Ale to w teorii, bo w praktyce praktycznie nikt się z takim czymś nie spotkał
• przy umowach-zleceniu lub o dzieło (są to umowy zawierane na gruncie prawa cywilnego) odpowiedzialność zleceniobiorcy jest równa wyrządzonej szkodzie i nie stosuje się do niej ograniczeń analogicznych dla regulacji KP. Zleceniobiorca może ponosić odpowiedzialność zarówno za nienależyte wykonanie umowy na podstawie art. 471 KC, jak i odpowiedzialność za zawinione działanie na podstawie art. 415 KC. Można zatem obciążyć zleceniobiorcę kosztami naprawienia szkody w pełnej wysokości na podstawie art. 415 KC, jeżeli szkoda powstała z winy zleceniobiorcy

Ponadto jeszcze jest kwestia obciążenia firmy, która aplikację stworzyła, kosztami powstałych z jej wykorzystaniem szkód. Tutaj wiele zależy od EULA, umowy sprzedaży, licencji na jakiej aplikacja została wydana oraz kilku innych kwestii.

Natomiast, zakładając czarny scenariusz - coś skopiesz, ABS nie zadziała i przez to zaczną ludzie ginąć - poza wyrzutami sumienia, za wiele Ci nikt nie zrobi. To jest odpowiedzialność firmy, żeby produkt odpowiednio sprawdzić i wdrożyć stosowne procedury jakości. Ty możesz (co pisałem wyżej) np. zostać obciążony max. 3-krotnością swojego wynagrodzenia, ale to dopiero w chwili, w której firma poniesie jakieś realne konsekwencje - np. otrzyma jakieś kary, sądowy nakaz zapłaty itp. Raczej mało realny scenariusz.

W automotive szeregowy programista nie poniesie jakiejś wielkiej odpowiedzialności z powodu własnego błędu (chyba że zrobił kuku celowo).

Nawet powiem, że to by musiała być naprawdę bieda firma, żeby ciągać programistę po sądach. W końcu, to że masz buga w poduszkach, to wynik zawalenia sprawy wielu warstw, nie tylko programistów robiących review ale też testerów różnej maści.

Bardziej obawiałbym się na twoim miejscu nakładu procesowego. Review i podpinanie wymagań pod każdą linijkę kodu, współpraca z paroma warstwami testerów (nierzadko hindusów...), dziwne stanowiska do żonglowania wymaganiami z klientem, zabetonowany kod ("już działa od 10 lat bez problemów, to nie chcemy ruszać"). Do tego najczęściej waterfall... w sumie w automotive masz v-model - jeszcze gorzej niż waterfall.

Ogólnie w automotive dodaj sobie pierwiastek niemieckiej myśli technologicznej - AUTOSAR to taka perełka.

Jeżeli nadal się boisz, to opowiem Ci historię pewnego kompilatora - kiedyś miał buga, że mieszały mu się zmienne ale "tylko jeżeli podobnie się nazywały i były zadeklarowane obok siebie". Myślisz że ktoś z autorów tego EnTeRpRiSoWeGo, certyfikowanego kompilatora poniósł jakieś konsekwencje?

Jasne mógłbym brać na obroty AUTOSAR-owe narzędzia ale mało ludzi wierzy jak się mu mówi, że ocertyfikowane narzędzie do generowania softu (m.in. do poduszek) nie zawsze domyka klamerki.

Ja pracuję w telekomunikacji i generalnie to jest tak że dana funkcjonalność przechodzi przez dużo rąk i oczu zanim trafi u klienta do sieci. Sam projekt rozwiązania robią ludzie mający 20+ lat doświadczenia, potem zespoły opracowują implementację cały czas konsultując z designerami i testując po kawałku(wymagane jest 100% pokrycia unit testami), przed wypchnięciem na mastera jest review(jeżeli commit jest duży to prosisz eksperta od danego obszaru o review) potem są spotkania z test managerami żeby uszczegółowić zakres testowy na różnych już wyższych szczeblach, potem się to mieli w automatycznych testach, potem jeszcze to klienci mielą w swoich labach i dopiero idzie to w żywą sieć. W korporacji pojedynczy programista nie ma na tyle podmiotowości żeby mógł osobiście za coś odpowiadać, nawet złamać procedur nie możesz bo jest to zazwyczaj fizycznie niemożliwe. Natomiast tak jak tu ktoś ostrzegał - narzut biurokratyczno-testowy jest duży, u mnie to jest 70-80% pracy.

Oggy napisał(a):

nawet złamać procedur nie możesz bo jest to zazwyczaj fizycznie niemożliwe. Natomiast tak jak tu ktoś ostrzegał - narzut biurokratyczno-testowy jest duży, u mnie to jest 70-80% pracy.

Ile takiej pracy dla finansów jest puszczanej do Eastern Europe, bo byle kto tego nie zrobi, polotu w tym tyle co u tańczącego słonia, a koszty trzeba ciąć?
Później zawiedzeni ambitni poszukiwacze wyzwań piszą, że znowu na rekrutacji obiecywali cuda a wyszło jak zwykle.
Sorry, na plantacjach programistów uprawia się to co w klimacie (naszym, Eastern Block) dobrze rośnie i daje zysk.

BTW, w słonecznej dolinie krzemu też narzekają na pracę na plantacji (nawet u Pana G). Uprawy inne ale robota ta sama.

Generalnie nie ma za bardzo odpowiedzialności, bo to nie jest tak ze klikasz push i kod już leci na produkcje i ludzie następnego dnia giną. Masz zwykle wielopoziomowy proces weryfikacji i walidacji, review, testy itd. Oczywiście jeśli by się okazało że zrobiłeś coś celowo, to inna sprawa, ale za jakiegoś buga, nawet jeśli byłby krytyczny, nie będzie odpowiadać szeregowy programista. Inna sprawa to oczywiście stres i wyrzuty sumienia, ale to kwestia indywidualna.

Tu masz to ładnie wyjaśnione:

Nie wiem jak w IT bo pracuje w webie ;d aczkolwiek w maju zaczynam w automovie ale tez web to chyba nikogo nie pozabijam ;). Aczkolwiek na studiach profesor z elektroniki narzekal na te normy co weszly. Bo musieli wiele dodatkowych rzeczy w projektach usprawniać pod nie aczkolwiek po chwili zadumy stwierdził, że jak kiedyś ktoś się zabił to zawsze były problemy a teraz jak instalacja spełnia normy to ty nie odpowiadasz, poza swoim sumieniem oczywiście. Myślę, że w takich miejscach jest podobnie jeśli CELOWO nie próbujesz zabijać ludzi to raczej firma ma odpowiednie procedury testowe, które gwarantują, że to co się wydarzy to nieszczęśliwy wypadek i tyle