Samolot, w przeciwieństwie np. Do strony internetowej, to system, w którym każda awaria w niektórych systemach jest całkowicie niedopuszczalna, ponieważ błędy w np. Monitorowaniu lotu mogą spowodować nieprawidłowe działanie autopilota i wykonanie nurkowania. Oczywiście tak się nie dzieje, ponieważ genialni inżynierowie z Boeinga i Airbusa sprawdzają autopilota, aby upewnić się, że nurkowanie nie jest nagle całkowicie akceptowalnym i bezpiecznym manewrem. A może komputer ulega awarii, a piloci nowszego samolotu przelotowego nie mogą już faktycznie latać samolotem. Oczywiście istnieją różne procedury bezpieczeństwa i redundancje wbudowane w te systemy, aby zapobiec awarii (zarówno oprogramowania, jak i samolotu).
Jednak z drugiej strony jest całkiem oczywiste, że oprogramowanie nie jest idealne - zarówno oprogramowanie open source, jak i oprogramowanie open source często ulegają awariom, a tylko najprostszy program „Hello World” nie zawodzi. W jaki sposób inżynierowie, którzy projektują systemy oprogramowania w branży lotniczej, medycznej i innych branżach związanych z życiem lub śmiercią, mogą przetestować swoje oprogramowanie, aby nie zawiodło (a jeśli zawiodło, przynajmniej zawiodło)?
Mam rozpaczliwą nadzieję, że nie wszyscy pójdziecie: „Och, pracuję dla Boeinga / Airbusa / (innej firmy) i tak nie jest! Baw się dobrze podczas następnej wizyty w szpitalu”.
Odpowiedzi:
Dużo pracy wykonałem w zakresie sterowania przemysłowego. Nie musi być w tak chwalebnym przemyśle jak lotnictwo. Prawie każda maszyna przemysłowa ma wystarczającą energię potencjalną, aby spowodować poważne obrażenia lub śmierć. Byłem w pobliżu, kiedy ludzie zostali ranni. Jeśli spędzasz większość czasu przy biurku w biurze, prawdopodobnie zdziwiłbyś się, jak niebezpieczne może być większość prac fabrycznych (a na pewno były do niedawna). Teraz mamy lepsze metody zabezpieczenia maszyn. Oto jak to działa w praktyce (choć różni się w zależności od jurysdykcji):
Istnieją standardy OSHA w USA i podobne (zwykle bardziej rygorystyczne) wytyczne w UE. Zazwyczaj zaczynają się od wymagania analizy ryzyka. Oznacza to, że sporządzasz listę wszystkich zagrożeń, a następnie kategoryzujesz te zagrożenia, biorąc pod uwagę takie rzeczy, jak to, jak często dana osoba byłaby narażona na ryzyko, jak łatwo jest uniknąć ryzyka (zależy od prędkości itp.) I co jest dotkliwością wyniku (cięcie, amputacja, śmierć itp.).
Wiele analiz dotyczy ochrony przed zagrożeniami. Jeśli umieścisz dużą klatkę wokół swojej maszyny i mocno ją przykręcisz, wtedy twoja maszyna będzie uważana za bezpieczną, jeśli elementy maszyny nie będą mogły przekroczyć osłony. Jeśli potrzebujesz narzędzia, aby wejść, jest to uważane za zadanie konserwacji, a osoby zajmujące się konserwacją powinny zostać przeszkolone w zakresie bezpiecznej pracy na maszynie. W rzeczywistości jednak większość maszyn wymaga regularnej interakcji z operatorami, dlatego musimy umieścić drzwi dostępowe w osłonach lub kurtynach świetlnych itp. Te drzwi i kurtyny świetlne muszą być monitorowane, a moc do zagrożeń, na które naraża się operator musi zostać odcięty w „niezawodny sposób” sterowania.
Na podstawie tej analizy ryzyko dzieli się na różne kategorie. Powszechną skalą klasyfikacji jest kategoria 1 do kategorii 4 (na podstawie normy EN 954-1). W oparciu o te kategorie jesteś prawnie zobowiązany do zapewnienia pewnego poziomu ochrony maszyny i bezpieczeństwa.
Na przykład kategoria 4 wymaga, aby:
Może to być trudne do osiągnięcia w praktyce, ale jest ułatwione dzięki dostępności standardowych komponentów, które są certyfikowane do kategorii 4. Na przykład jednym wspólnym elementem w tych systemach jest przekaźnik bezpieczeństwa. To więcej niż tylko przekaźniki mechaniczne:
Jak widać, są to skomplikowane urządzenia. Typowe koszty wynoszą od 200 do 600 USD dla każdego przekaźnika bezpieczeństwa. Oczywiście w tych urządzeniach jest oprogramowanie. Aby uzyskać certyfikat przekaźnika bezpieczeństwa, zwykle musisz postępować zgodnie z następującym projektem:
Po zaprojektowaniu systemu bezpieczeństwa dla swojej maszyny, przy użyciu komponentów z oceną bezpieczeństwa, musisz sprawdzić projekt i podstemplować go przez profesjonalnego inżyniera. Następnie budujesz maszynę. Następnie P.Eng. przejrzy konstrukcję maszyny, upewniając się, że została zbudowana zgodnie z projektem. Udokumentują to i przeprowadzą na nim testy, aby upewnić się, że działa zgodnie z oczekiwaniami. Nazywa się to przeglądem przed uruchomieniem (PSR) i nie jest przeprowadzane w każdej jurysdykcji. Po przejściu PSR operator może uruchomić maszynę.
W ostatnich latach nastąpiły pewne rewolucje w systemach bezpieczeństwa. Przez pewien czas nikt nie ufał przesyłaniu danych bezpieczeństwa przez sieć, więc to, co zwykle nazywane jest „rozproszonymi systemami we / wy”, takimi jak DeviceNET i EtherCAT, nie było dozwolone w części dotyczącej bezpieczeństwa systemu. Jednak najnowsze protokoły umożliwiają teraz działanie urządzeń bezpieczeństwa w tych sieciach przemysłowych. Protokoły wykorzystują wiadomości ze znacznikiem czasu i podwójne przetwarzanie redundantne na obu końcach połączenia.
Przekaźniki bezpieczeństwa powoli podążają drogą ptaka dodo, zastępowane przez bardziej skomplikowane sterowniki PLC bezpieczeństwa, które są jak sposób na zbudowanie logiki bezpieczeństwa w języku schematów bloków funkcyjnych. Ponownie, te bezpieczne sterowniki PLC wykorzystują wszystko nadmiarowe. Po zatwierdzeniu programu, przed uruchomieniem maszyny, P.Eng. stempluje program, a program / PLC zostanie zablokowany hasłem. Zajmuje również skrót programu, który jest zapisywany w dokumentacji (tak naprawdę P.Eng. Naprawdę stempluje).
Po zaprojektowaniu systemu bezpieczeństwa logika, którą piszesz, aby sterować samą maszyną, może być bardzo prosta. Programiści często rozbijają maszyny, powodując tysiące dolarów szkód, ale przynajmniej nikt nie odniesie obrażeń.
źródło
Nastąpił poważny ruch w kierunku formalnej weryfikacji zamiast losowych testów funkcjonalnych.
Agencje rządowe, takie jak NASA i niektóre organizacje obronne, wydają coraz więcej na te technologie.
Nadal są PITA dla przeciętnego programisty, ale często są bardziej skuteczne w testowaniu krytycznych systemów.
Istnieje również tendencja do wypróbowywania większej liczby technik ze środowisk akademickich, na przykład do sprawdzania poprawności wielowątkowego kodu.
źródło
To zależy od oprogramowania. Na przykład w samolotach jest zwykle przetwarzanie podwójnie nadmiarowe dla systemów krytycznych; w skrajnym przypadku mogą być zastosowane 2 różne konstrukcje sprzętu i dwa niezależnie opracowane fragmenty s / w, po jednym na każdym. Oboje obliczają się i sprawdzają wzajemnie. Nie jest to niezawodne i jest niezwykle drogie.
Jeśli chodzi o takie rzeczy, jak testowanie systemów lotniczych, przeprowadzana jest seria testów - testy systemów związanych z lotem trwają miesiące, a jeśli wprowadzisz jakiekolwiek zmiany, wymagana jest cała seria ponownych testów. Zwykle odbywa się to w symulatorze, który może być faktycznie wypełniony prawdziwymi częściami samolotu (np. Kokpitem) z, powiedzmy, symulowanym silnikiem lub podobnym. Jak można sobie wyobrazić, jest to również koszmarnie kosztowne w budowie. Zmiany są oceniane na podstawie formalnego programu testowego, a następnie uruchamiane w prawdziwym samolocie podczas lotów testowych. Podczas wykonywania testów takich jak „zakłócony funkcjonalny”, w tym miejscu zmieniony element może wykonywać swoje normalne czynności, a wszystko jest sprawdzane / sprawdzane pod kątem braku szkodliwego efektu. To również kosztuje dużo pieniędzy i może potrwać tygodnie.
Znam jeden przykład, w którym wymagana była bardzo prosta zmiana systemu lotu - tak prosta, że byłbyś oszołomiony tym, jak niewielka. Jednak ponowny test trwałby ponad 3 miesiące i kosztowałby około 1 mln USD.
Kiedy wchodzisz do medycyny, musisz przejść całą serię przeszkód regulacyjnych związanych nie tylko z testowaniem, ale z procesami rozwoju i dokumentacją.
Wszystkie te pola są dużym krokiem naprzód w porównaniu z miejscami, w których pobiera się trochę kodu PHP dla strony internetowej. Jest powolny, żmudny, trudny, nudny, nużący, drobiazgowy i bardzo drogi. Weź normalne koszty opracowywania / testowania i pomnóż przez około 100, a zbliżasz się do celu.
źródło
Dla oprogramowania NASA wahadłowca kosmicznego przeczytaj, że piszą właściwe rzeczy . Dla FDA (US Food and Drug Administration) przeczytaj to
źródło
Ponieważ masz już wystarczająco dużo świetnych i pouczających odpowiedzi, oto moje zdanie.
To proste - pierwszy test jest zawsze przeprowadzany na samych programistach. Ma tendencję do utrzymywania niskiej liczby błędów i zapewnia, że tylko wysokiej jakości programiści są utrzymani na liście płac.
źródło
Oprogramowanie o kluczowym znaczeniu dla życia nie jest testowane na żadnym innym standardzie niż „wydaje się, że działa” , ponieważ jest wykonywane wszędzie.
Cała inwestycja przeznaczana jest albo na to, co wcześniej działało, albo na projekty, które pozwalają nie-programistom tworzyć lepsze oprogramowanie.
ps Brak komentarzy do pierwszego
-1
, ale chętnie przyjmę-1
każde odniesienie, które sprzeciwia się mojemu stwierdzeniu.Czy mogę wziąć +1 za każde odniesienie do krytycznego oprogramowania, które nie jest dobrze zaprojektowane lub przetestowane? Simson Garfinkel dokumentuje dziesięć przypadków w artykule na temat WIRED.
źródło
Nie ma jednej odpowiedzi na wszystkie przypadki. Indywidualny producent decyduje, jak zaprojektować i przetestować swoje oprogramowanie. Ale cały proces tworzenia oprogramowania musi być zgodny ze specyfikacjami formalnymi.
Na przykład podczas tworzenia oprogramowania dla urządzeń medycznych należy przestrzegać normy IEC 62304 dla oprogramowania dla urządzeń medycznych. (Niestety mogę tylko link do wikipedii, ponieważ nie jest ona darmowa). Prawie każdy kraj na świecie wymaga przestrzegania tego standardu.
To, jak surowe są te wymagania, zależy od ryzyka szkody. Np. Urządzenie podtrzymujące życie miałoby największe ryzyko uszkodzenia (pewna śmierć w przypadku awarii systemu), podczas gdy system współpracujący z diagnostyką choroby ma mniejsze ryzyko (możliwa śmierć, jeśli śmiertelna choroba nie zostanie poprawnie zdiagnozowana, jeśli system ulegnie awarii).
Ale to w zasadzie mówi, że musi istnieć identyfikowalność od wymagań do oprogramowania. Musisz przeprowadzić weryfikację oprogramowania. To nie określa, co to jest weryfikacja. Mogą to być testy jednostkowe, może być przegląd kodu. W przypadku urządzeń podwyższonego ryzyka należy ręcznie przejrzeć interfejsy między jednostkami oprogramowania (o ile rozumiem i pamiętam). I oczywiście wiele innych zasad. Och, i musisz napisać dużo dokumentacji, aby udokumentować swoją pracę.
Standard nie zabrania zwinnego rozwoju, chociaż podczas jego czytania wydaje się, że został napisany z myślą o rozwoju wodospadu.
Nie wiem o innych obszarach rozwoju oprogramowania, takich jak lotnictwo, pociągi, samochody itp. Ale zakładam, że istnieją inne podobne formalne wytyczne.
źródło
Stosowanych jest wiele technik, w tym między innymi:
Ale technika numer jeden to:
Oprogramowanie statku kosmicznego wymaga więcej wysiłku do przetestowania niż do zaprojektowania i zakodowania.
Samoloty przechodzą kilkuletnie próby w locie, w których samolot znajduje się w ekstremalnych sytuacjach. Testuje to nie tylko strukturę fizyczną, ale także oprogramowanie.
źródło
Artykuł „Doskonałe oprogramowanie” autorstwa Jacka Ganssle'a na EETimes z dnia 01.03.2009 12:00 EST. Kilka punktów stamtąd:
Co ciekawe, w odniesieniu do oprogramowania komercyjnego, dane zebrane przez Capers Jones sugerują, że „oprogramowanie ogólnie wykazuje skuteczność usuwania defektów (odsetek błędów usuniętych przed wysyłką) na poziomie 87%. Oprogramowanie układowe osiąga znacznie lepsze 94%”. Dla mnie żadne z nich nie jest prawie idealne. W artykule, o którym wspominał wcześniejszy autor, wskazano, że zespół promu kosmicznego NASA osiągnął wskaźnik usuwania błędów w 99%, ale koszt wynosi około 35 milionów rocznie za około 400 tys. Linii kodu.
Bardziej interesujący wydaje się bardziej interesujący artykuł „Oprogramowanie dla niezawodnych systemów” tego samego autora z 11.01.2009. Można to streścić w następujący sposób:
Według mojej pamięci HP ćwiczył projekt na zamówienie prawie dziesięć lat temu. W małym zespole, 500 000 linii kodu, tylko 2 błędy zgłoszono po dostawie. Bardzo imponujące.
Moim zdaniem niezawodne lub doskonałe oprogramowanie można osiągnąć tylko wtedy, gdy koszt nie jest zbyt wysoki. Ramy lub automatyzacje są koniecznością.
źródło
Zwykle mają blokadę sprzętową, która jest używana jako bezpieczna w razie awarii.
Np. Standardowe projekty złych pól tekstowych dla robotów-zabójców zawsze mają przełącznik „zabicia”: P
źródło
Każda branża ma swój własny zestaw agencji regulacyjnych, które mają wymagania dotyczące testowania i dokumentacji sprzętu i oprogramowania związanego z bezpieczeństwem. Rozważ ten plik PDF z Underwriters Laboratory (UL), który wprowadza standard UL 1998: http://www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf
W tym dokumencie znajdują się odniesienia do wielu innych powiązanych z UL, CSA i IEC.
Zazwyczaj oprogramowanie związane z bezpieczeństwem będzie posiadało redundantne obwody sprzętowe lub będzie wymagać innych redundantnych funkcji sterowania w celu zapewnienia bezpiecznej pracy i bezpiecznych trybów awarii.
źródło