W jaki sposób testowane jest oprogramowanie w krytycznych systemach życia lub śmierci?

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”.}

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:

Pojedynczy błąd w każdej z tych części nie powoduje utraty funkcji bezpieczeństwa.

Pojedynczy błąd jest wykrywany z następnym żądaniem funkcji bezpieczeństwa lub przed nim, lub jeśli nie jest to możliwe, kumulacja błędów może nie spowodować utraty funkcji bezpieczeństwa.

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:

• Są przeznaczone do monitorowania podwójnych redundantnych kanałów wejściowych, więc jeśli masz czujnik, który wykrywa stan awarii (jak otwarte drzwi ochronne), zwykle ma dwa styki z redundantnymi obwodami. Przekaźnik monitoruje oba kanały, a jeśli którykolwiek z nich się otworzy, zużywa zasilanie siłowników, ale jeśli oba nie wypadną w tym samym czasie, przechodzi w stan awarii i maszyny nie można uruchomić ponownie, dopóki nie zostanie naprawiona .
• Przekaźnik wykorzystuje również impulsy elektryczne na tych liniach i wykorzystuje te sygnały do ​​monitorowania skrzyżowanych lub zwartych przewodów, dzięki czemu może wykryć awarię okablowania.
• Po stronie wyjściowej wykorzystuje zestaw podwójnych obwodów do napędzania cewek wyjściowych, więc jeśli jeden z nich zawiedzie w stanie „włączenia”, drugi powinien zapobiec pobudzeniu wyjścia. Dodatkowo są one monitorowane, a jeśli zostanie wykryty błąd, uniemożliwia działanie. Same cewki są w rzeczywistości przekaźnikami o podwójnej sile, co oznacza redundantne fizyczne przekaźniki na wyjściu, a także gwarantują, że styki każdego pojedynczego przekaźnika są fizycznie połączone ze sobą, tak że jeden styk z, powiedzmy 4, nie może sam się zablokować. Są one również monitorowane.
• Obejmuje również wejście do monitorowania pomocniczego, normalnie zamkniętego styku przy kontrolowanym obciążeniu. Jeśli wyłączy to wyjście, musi zobaczyć normalnie zamknięty styk, co oznacza, że ​​potwierdza, że ​​wyłączył stycznik silnika lub cokolwiek to było, zanim będzie mógł ponownie działać w stanie włączenia.

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:

• Dwa redundantne procesory, zwykle pochodzące od różnych dostawców, oparte na różnych projektach.
• Kod działający na każdym procesorze musi zostać opracowany przez dwa zespoły pracujące w odizolowanych warunkach. Dzięki temu pojedynczy błąd oprogramowania nie jest pojedynczym punktem awarii.
• Wyjście obu procesorów musi się zgadzać, w przeciwnym razie wystąpi błąd przekaźnika bezpieczeństwa.

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ń.

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.

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.

Dla oprogramowania NASA wahadłowca kosmicznego przeczytaj, że piszą właściwe rzeczy . Dla FDA (US Food and Drug Administration) przeczytaj to

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.

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ę -1każ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.

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.

Stosowanych jest wiele technik, w tym między innymi:

• formalny projekt i / lub walidacja
• surowe standardy kodowania unikające wymyślnego programowania, takie jak dynamiczny przydział pamięci
• bardzo wymagający inżynierowie jakości
• wiele technik analizy statycznej, takich jak przegląd kodu, drzewa błędów, FMECA, ...

Ale technika numer jeden to:

• TESTOWANIE

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.

Artykuł „Doskonałe oprogramowanie” autorstwa Jacka Ganssle'a na EETimes z dnia 01.03.2009 12:00 EST. Kilka punktów stamtąd:

• „Teoretycznie oprogramowanie jest jedynym komponentem, który może być doskonały, i zawsze powinien to być nasz punkt wyjścia”. - Tak powiedział Jesse Poore. Podążając za jego stroną internetową dowiesz się, jak można stworzyć idealne oprogramowanie bez większych kosztów niż zwykłe oprogramowanie.
• Istnieją dostawcy przemysłowi wysoce niezawodnych systemów operacyjnych. W artykule wspomniano o Mircrium i Green Hills. Po stronie internetowej Micrium znajduje się lista standardów certyfikacji. To muszą być procesy i zasady, którymi kieruje się przemysł. Opiera się to na formalnej weryfikacji, ale bardzo odwraca się od teorii.

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:

• Jeśli chodzi o proces rozwoju, przemysł przestrzega DO-178B lub IEC61508. Podkreśla testowanie z największym zasięgiem. Ale niewiele jest dowodów na skuteczność tego.
• Urząd certyfikacji, Komitet ds. Systemów Niezawodnego Oprogramowania, opublikował książkę zatytułowaną „Oprogramowanie dla niezawodnych systemów - wystarczające dowody”. To dobra referencja.
• Książka zasadniczo prosi o trzy rzeczy: [1] Ustanowić wyraźne reguły dla testów niezawodności. [2] Testy niezgodne z regułami, ale także upewnienie się, że testy są zrozumiałe dla zwykłych klientów lub organów regulacyjnych o czasie mniejszym niż czas spędzony przez programistów. [3] Upewnij się, że to eksperci w dziedzinie inżynierii oprogramowania i problematycznej dziedziny opracowują i testują.
• Dostawca oprogramowania musi zobowiązać się do gwarancji lub innych środków zaradczych w przypadku awarii oprogramowania.
• Używaj bezpiecznego języka, a konkretnie nie C. Sugeruje się SPARK.
• Projektowanie pod kątem kontraktu jest jedną z zalet SPARK. Projektowanie na zamówienie jest ważną technologią pozwalającą osadzać testy w każdym wywołaniu funkcji / metody i zawsze wykonywać je w czasie wykonywania. Więcej niż zwykły aser () w dawnych czasach, umowa może również obejmować testy pod kątem zamiarów strukturalnych i upewnić się, że żadne naruszenie nie będzie można wślizgnąć w późniejszym okresie cyklu konserwacji, gdy pierwotni programiści przeszli na inne projekty. Istnieją dowody na to, że projekt kontraktu wytworzył bardzo niezawodne oprogramowanie. SPARK i jego narzędzia mogą służyć do generowania przypadków testowych certyfikacji w celu uproszczenia procesu certyfikacji.

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ą.

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

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.