Як тестується програмне забезпечення, яке використовується у критичних системах життя чи смерті?


51

Літак, на відміну, наприклад, від веб-сайту, - це система, де будь-які збої в певних системах є абсолютно неприйнятними, оскільки помилки, наприклад, моніторинг польоту, можуть призвести до несправності автопілота і занурення. Очевидно, цього не відбувається, оскільки геніальні інженери Boeing та Airbus перевіряють автопілот, щоб переконатися, що він не раптом вирішить занурення - цілком прийнятний і безпечний маневр. Або, можливо, комп'ютер виходить з ладу, і пілоти в новіших літальних апаратах не можуть реально літати на літаку. Звичайно, в ці системи вбудовані різні процедури безпеки та надмірності для запобігання аварій (як програмного забезпечення, так і літака).

Однак, з іншого боку, цілком очевидно, що програмне забезпечення не є досконалим - і програмне забезпечення з відкритим кодом, і з закритим кодом регулярно виходить з ладу, і лише найпростіша програма «Hello World» не виходить з ладу. Як інженерам, які проектують програмні системи в галузі аеронавігаційної, медичної та іншої життєдіяльності чи смерті, вдається випробувати своє програмне забезпечення, щоб воно не вийшло з ладу (і якщо воно не вийшло, принаймні витончено)?

Я відчайдушно сподіваюся, що ви не все збираєтеся їхати: "О, я працюю на Boeing / Airbus / (якусь іншу компанію), і це не так! Будьте веселі в наступному рейсі / відвідуванні лікарні".


8
Враховуючи випадок Therac25 та батарею Patriot, які не зафіксувались, очевидно, недостатньо добре.
Лорен Печтел

@Loren Ну, я не сумніваюся, що винятків немає. З іншого боку, я ніколи не читав про Airbus A320 (літаючий літальний літак), щоб коли-небудь відчути значну програмну помилку, яка призвела до близьких травм / травм / загибелі, і їх було зроблено понад 4000.
waiwai933

3
"Привіт Світ" також може провалитися. lol
xandy

1
@waiwai - насправді це сталося рік або близько тому - несправний датчик вказував на те, що літак піднімався занадто круто і збирається зупинитися. Спроба комп’ютера повернутися до рівня польоту насправді була зануренням. Жодної аварії, але траплялися тілесні ушкодження / пошкодження пасажирів та сипучих предметів, які кидалися навколо кабіни.
Том Кларксон

6
Хіба вони не використовують ув'язнених, які мають ліцензії пілотів?
JeffO

Відповіді:


29

Я багато пропрацював у галузі промислового контролю. Це не повинно бути в такій славетній галузі, як аерокосмічний. Практично кожна промислова машина має достатню кількість потенційної енергії, щоб спричинити серйозні травми або смерть. Я був поруч, коли люди були поранені. Якщо ви проводите більшу частину свого часу за столом в офісі, ви, мабуть, здивуєтеся, наскільки небезпечними можуть бути більшість заводських робочих місць (і, безумовно, були до недавнього часу). Зараз у нас є кращі методи захисту машини. Ось як це працює на практиці (хоча це залежить від юрисдикції до юрисдикції):

У США існують стандарти OSHA та подібні (як правило, більш суворі) інструкції в ЄС. Вони, як правило, починаються з того, щоб вимагати зробити аналіз ризику. Це означає, що ви складаєте список усіх небезпек, а потім класифікуєте ці небезпеки, беручи до уваги такі речі, як часто людину піддаватимуть ризику, наскільки легко уникнути ризику (залежить від швидкості тощо) та що - ступінь тяжкості результату (поріз, ампутація, смерть тощо).

Багато аналізу стосується небезпек щодо охорони. Якщо навколо машини встановити велику клітку і закрутити її щільно, то її вважають безпечною, якщо компоненти машини не можуть порушити захист. Якщо вам потрібен інструмент для входу, це вважається завданням з технічного обслуговування, а люди з технічного обслуговування повинні бути навчені безпечно працювати на машині. Насправді, однак, більшість машин потребує регулярної взаємодії з операторами, тому нам доводиться ставити двері для доступу в охорону, або світлі завіси і т. Д. Ці двері та світлі штори потрібно контролювати, а також небезпеку небезпеки, яку оператор наражає на себе має бути вимкнено "контрольно надійним" способом.

Виходячи з цього аналізу, ризик класифікують у різні категорії. Поширеною шкалою класифікації є категорії від 1 до 4 категорії (на основі стандарту EN 954-1). Виходячи з цих категорій, ви законодавчо зобов'язані забезпечити певний рівень охорони та безпеки машини.

Наприклад, категорія 4 вимагає:

Поодинока несправність у кожній із цих частин не призводить до втрати функції безпеки.

Одинична несправність виявляється за допомогою або перед наступним запитом до функції безпеки, або якщо це неможливо, накопичення несправностей може не спричинити втрату функції безпеки.

Це може бути важко досягти на практиці, але це спрощується наявністю стандартних компонентів, сертифікованих до категорії 4. Наприклад, одним із загальних компонентів у цих системах є реле безпеки. Це більше, ніж просто механічні реле:

  • Вони розроблені для моніторингу подвійних надлишкових вхідних каналів, тому якщо у вас є датчик, який визначає стан несправності (як, наприклад, відкрита охорона двері), як правило, він має два контакти із зайвими ланцюгами. Реле контролює обидва канали, і якщо один з них відкриється, він виводить живлення з вашими приводами, але якщо вони обидва не випадають одночасно, він переходить у стан несправності, і машина не може бути перезапущена до ремонту .
  • Реле також використовує електричні імпульси на цих лініях і використовує ці сигнали для моніторингу перехрещених або коротких проводів, тому він може виявити несправність проводки.
  • З боку виходу він використовує набір подвійних ланцюгів для приведення вихідних котушок, тому, якщо один вийшов з ладу в стан "увімкнено", інший повинен перешкоджати напрузі виходу. Крім того, вони контролюються, і якщо виявлена ​​несправність, це перешкоджає роботі. Самі котушки - це фактично реле, що керуються подвійною силою, що означає надлишкові фізичні реле на виході, плюс гарантія того, що контакти кожного реле фізично пов'язані між собою, так що один контакт із, скажімо 4, не може застрягнути сам. Вони також контролюються.
  • Він також включає вхід для контролю допоміжного нормально закритого контакту від навантаження, яким ви керуєте. Якщо він вимикає вихід, він повинен побачити нормально замкнутий контакт замикання, тобто він перевіряє, що він вимкнув контактор двигуна, або що б там не було, перш ніж йому знову дозволити спрацьовувати в стані.

Як ви можете сказати, це складні пристрої. Типові витрати становлять від $ 200 до $ 600 для кожного реле безпеки. Очевидно, що в цих пристроях є програмне забезпечення. Щоб сертифікат безпеки був сертифікований, вам, як правило, слід керуватися таким дизайном:

  • Два надлишкових процесора, як правило, отримані у різних постачальників на основі різних конструкцій.
  • Код, що працює на кожному процесорі, повинен бути розроблений двома командами, що працюють в ізольованих умовах. Це запобігає появі однієї помилки програмного забезпечення єдиною точкою відмови.
  • Вихід обох процесорів повинен узгоджуватися, інакше несправності реле безпеки.

Після того, як ви створили систему безпеки для своєї машини, використовуючи компоненти, що оцінюють безпеку, вам доведеться переглядати конструкцію та штампувати її професійним інженером. Потім ви будуєте верстат. Потім P.Eng. переглянемо конструкцію машини, переконавшись, що вона була побудована до проекту. Вони задокументують його та виконають деякі тести на ньому, щоб переконатися, що він працює, як очікувалося. Це називається огляд перед початком (PSR) і проводиться не у всіх юрисдикціях. Після того як PSR пройде, вам дозволяється оператор запускати машину.

В останні роки в системах безпеки відбулися певні революції. Деякий час ніхто не довіряв передачі даних про безпеку по мережі, тому, що зазвичай називається "розподіленими системами вводу / виводу", такими як DeviceNET та EtherCAT, заборонено входити в безпечну частину системи. Однак останні протоколи тепер дозволяють пристроям безпеки працювати над цими промисловими мережами. Протоколи використовують повідомлення з печаткою часу та подвійну надлишкову обробку на обох кінцях з'єднання.

Реле безпеки повільно йдуть шляхом птаха Додо, замінене на більш складні ПЛП безпеки, які є як спосіб побудувати логіку безпеки на мові діаграми функціональних блоків. Знову ж таки, ці PLC-системи безпеки використовують все зайве. Коли програма затверджена, перед введенням машини в експлуатацію, P.Eng. зафіксує печатку програми і програма / PLC буде заблокована паролем. Він також займає хеш програми, і той хеш записується в документацію (саме так P.Eng. Насправді штампує).

Тепер, коли ви створили вашу систему безпеки, логіка, яку ви пишете, щоб керувати самою машиною, може стати дуже сидінням штанів. Програмісти часто вибивають з ладу машини, що завдають шкоди тисячам доларів, але принаймні ніхто не постраждає.


20

Існує серйозний крок до формальної перевірки, а не до випадкового функціонального тестування.

Урядові установи, такі як NASA та деякі оборонні організації, все більше і більше витрачають на ці технології.

Вони все ще є PITA для середнього програміста, але вони часто ефективніші при тестуванні критичних систем.

Існує також тенденція випробовувати більше методів у наукових колах для таких речей, як перевірка багатопотокового коду.


6
Написавши програмне забезпечення для наземного контролю для управління місією NASA та побачивши фрагменти старого та нового коду польоту, такого акценту немає. Гаразд, через збільшення чистої кількості, можливо, НАСА витрачає більше на КК, ніж будь-коли раніше, але увага, зосереджена на кожному застосуванні, значно нижча, ніж це було, коли космічна програма була молодою. Досі важлива увага приділяється критичним питанням безпеки, але критична місія потребує лише менш вичерпного тестового набору, і навіть здається, що критична перевірка безпеки з часом знижується.
Бен Войгт

7
Зауважте, що я не погоджуюся з тим, що формальна перевірка може бути дуже ефективною і важливою для досягнення найвищого рівня надійності. Просто менеджери дізналися, скільки це коштує, і, зіткнувшись із все більш складним програмним забезпеченням, пояснюють, що вони більше не можуть витрачати стільки на вимогу та на рядок коду. Правильним підходом було б розподіл системи та збереження критичних частин невеликими, але я не бачив цього зроблено ефективно, в результаті чого керівництво оголосило весь офіційний процес перевірки непомірно дорогим.
Бен Войгт

2
@Ben Voight: Якби я був космонавтом, мене би сильно занепокоїв ваш звіт.
Увімкнення

1
@Orbling: Космонавтам, мабуть, варто було б кинути деяку вагу навколо проблеми, але для початку вони є групою осіб, які вживають великих ризиків. Існує момент, коли ви зменшили ризики, які можете контролювати на порядок менше, ніж ті, які ви не можете, і це не дуже ефективно, щоб тримати гроші, і дискусійно, чи до цього дійшли методи, які я бачив у використанні бал. Деякі високопоставлені менеджери, безумовно, вірили, що вони це зробили.
Бен Войгт

1
І сумно думати, що не дуже багато людей слухали Діккстру, який тривав і проводив офіційну перевірку з 60-х років. Як сказав Ніцше: "Деякі чоловіки народжуються посмертно".
Дурненький

12

Це залежить від програмного забезпечення. Наприклад, у літаках зазвичай відбувається подвійне надмірне оброблення для критичних систем; в крайньому випадку, може використовуватися 2 різних конструкції обладнання та два незалежно розроблених шматка / с / ш, по одному для роботи на кожному. Вони обидва обчислюють та перехресно перевіряють один одного. Це не є надійним і надзвичайно дорогим.

Якщо мова йде про такі речі, як тестування літальних систем, робиться ряд випробувань - тестування систем, пов’язаних з польотами, займає місяці, і якщо ви взагалі внесете якісь зміни, потрібно запустити цілу серію повторних випробувань. Зазвичай це робиться в тренажері, який фактично може бути повним справжніх частин літака (наприклад, кабіни) з, скажімо, імітованим двигуном або подібним. Як ви можете собі уявити, це також жахливо дорого будувати. Зміни оцінюються відповідно до офіційної програми тестування, а потім виконуються в реальному літальному апараті в тестових польотах. По ходу виконуються такі тести, як "порушені функціональні" тести, саме тут зміненому елементу дозволяється виконувати його звичайні речі, і все перевіряється / перевіряється, щоб не було шкідливого ефекту. Це також коштує великих грошей і може зайняти тижні.

Я знаю один із прикладів, коли потрібна дуже проста зміна системи польоту - настільки простий, що ви були б приголомшені настільки неповнолітньою. Однак повторний тест на це зайняв би> 3 місяці і коштуватиме щось на зразок 1 млн доларів.

Коли ви потрапляєте на медичну допомогу, існує ціла низка регуляторних перешкод, пов'язаних не лише з тестуванням, але з процесами розробки та документацією.

Усі ці поля є великим кроком від місць, які витісняють трохи PHP-коду для веб-сайту. Це повільно, кропітко, важко, нудно, нудно, прискіпливо і дуже дорого. Візьміть собі звичайні витрати на розробку / тестування і помножте приблизно на 100, і ви наближаєтесь до позначки.


Приклад "2 різних апаратних конструкцій, що використовуються, та двох незалежно розроблених частин з / п, по одній для запуску на кожному" був би цікавим. Не погоджуючись, просто цікаво.
Брайан Карлтон

1
@Brian: Знайомий приклад для двох різних HW, 2 незалежно розроблених ПЗ можна знайти, наприклад, у контролері протиблокувальної гальмівної системи. Дивіться, наприклад, infineon.com/cms/jp/product/applications/automotive/safety/… який використовує дві різні архітектури процесора (8-бітну та 16-бітну) в одному ІМС.
Schedler

4
Три ще краще. З двома ви знаєте лише, що один з них не так. Маючи три, ви можете проголосувати. AFAIK, у Airbus A380 є три льотні комп’ютери від двох виробників.
Йорг W Міттаг

Роки тому я натрапив на кілька військових головних дисплеїв, розроблених таким чином. Моя здогадка полягає в тому, що за вартістю багато з цих прийомів використовуються не стільки, скільки раніше.
quick_now


3

Оскільки ви вже отримали достатньо чудових та інформативних відповідей, ось мій погляд.

Це просто - перший тест завжди робиться на самих програмістах. Це має тенденцію до того, щоб кількість помилок залишалася низькою і гарантувала, що у програмі збереження лише якісних програмістів.


3

Критичне для життя програмне забезпечення не тестується на будь-який стандарт, окрім "здається, що працює" , як це робиться всюди.

Усі інвестиції спрямовуються або на те, що, здавалося, працювало раніше, або на проекти, що дозволяють непрограмістам виробляти краще програмне забезпечення.

ps Немає коментарів до першого -1, але я би радий взяти -1за кожну довідку, яка протидіє моїй заяві.

Чи можу я взяти +1 за кожну оцінку, яку я вважаю, що критичне програмне забезпечення не є добре розробленим чи перевіреним? Сімсон Гарфінкел документує десять випадків у статті про WIRED.


Це, на жаль, все занадто точно.
Бен Войгт

Звичайно, я взяв вас за цю пропозицію за -1.
Брайан Карлтон

@Brian Carlton Ви не вказали посилання ...
Апалала

А як щодо DO-178, MOPS для GPS ... Принаймні, якщо я працюю, тестування може зайняти більше року. Зауважте, що тестування не гарантує, що код не містить помилок та відповідає технічним умовам у кожному можливому випадку.
jinawee

2

Немає однієї відповіді на всі випадки. Індивідуальний виробник вирішує, як створити та протестувати програмне забезпечення. Але весь процес розробки програмного забезпечення повинен відповідати формальним специфікаціям.

Наприклад, створюючи програмне забезпечення для медичних пристроїв, ви повинні дотримуватися стандарту IEC 62304 щодо програмного забезпечення для медичних пристроїв. (На жаль, я можу посилатися лише на вікіпедію, оскільки вона не є безкоштовною). Практично кожна країна світу вимагає дотримання цього стандарту.

Наскільки суворі ці вимоги, залежить від ризику заподіяння шкоди. Наприклад, пристрій для життєзабезпечення мав би найбільший ризик заподіяти шкоду (певна смерть, якщо система не працює), тоді як система, яка працює з діагностикою захворювання, має менший ризик (можлива смерть, якщо термінальна хвороба не була діагностована правильно, якщо система не працює).

Але в основному це говорить про те, що слід відстежувати вимоги до програмного забезпечення. Ви повинні виконати перевірку програмного блоку. Це не вказує, що таке верифікація. Може бути одиничне тестування, може бути огляд коду. Для пристроїв підвищеного ризику потрібно вручну переглянути інтерфейси між програмними підрозділами (наскільки я розумію і пам’ятаю). І звичайно багато інших правил. О, і ви повинні написати багато документації, щоб документувати свою роботу.

Стандарт не забороняє гнучку розробку, хоча при читанні здається, що це було написано з урахуванням розвитку водоспаду.

Я не знаю про інші сфери розробки програмного забезпечення, такі як авіація, потяги, машини тощо. Але я припускаю, що існують інші подібні формальні настанови.


1

Використовується багато методик, включаючи, але не обмежуючись ними:

  • формальне оформлення та / або затвердження
  • суворі стандарти кодування, уникаючи фантазійного програмування, наприклад, динамічного розподілу пам'яті
  • дуже вимогливі до якості інженери
  • методики статичного аналізу manys, такі як огляд коду, дерева несправностей, FMECA, ...

Але техніка номер один:

  • ТЕСТУВАННЯ

Програмне забезпечення космічного корабля потребує більше зусиль для тестування, ніж проектування та кодування в першу чергу.

Літаки проходять декілька років льотних випробувань, коли літак підводиться до екстремальних ситуацій. Це перевіряє не тільки фізичну структуру, але і програмне забезпечення.


1

Є стаття "Ідеальне програмне забезпечення" Джека Гансле на EETimes від 1.03.2009 00:00 EST. Кілька пунктів звідти:

  • "Теоретично програмне забезпечення - це єдиний компонент, який може бути ідеальним, і це завжди повинно бути нашою відправною точкою". - Це говорить Джессі Пур. Перейшовши на його веб-сторінку, ви дізнаєтесь, як ідеальне програмне забезпечення можна зробити не набагато більше, ніж звичайне програмне забезпечення.
  • Є промислові постачальники високонадійних ОС. У статті згадували Міррікум та Зелені пагорби. На веб-сторінці Micrium є перелік стандартів на сертифікацію. Це повинні бути процеси та правила, якими слід керувати галузь. Це засновано на формальній валідації, але багато чого відхилилось від теорії.

Що цікаво, що стосується комерційного програмного забезпечення, дані, зібрані Capers Jones, говорять про те, що "програмне забезпечення взагалі має ефективність усунення дефектів (відсоток помилок, видалених перед відправкою) 87%. Прошивка набирає набагато кращі 94%". Для мене жодне з них не є ідеальним. У статті, про яку згадували раніше відповіді, вказується, що команда космічних човнів NASA досягла 99% швидкості видалення помилок, але вартість становить 35 мільйонів на рік для приблизно 400 000 рядків коду.

Більш цікава стаття «Програмне забезпечення для надійних систем» того ж автора від 11/1/2009, здається, більш актуальною. Це можна підсумувати так:

  • Щодо процесу розробки, то галузь слідувала за DO-178B або IEC61508. Це підкреслює тестування з найбільшим покриттям. Але про ефективність цього можна знайти небагато доказів.
  • Орган із сертифікації, Комітет з сертифікованих програмних систем, опублікував книгу під назвою "Програмне забезпечення для надійних систем - достатньо доказів". Це хороша довідка.
  • В основному книга вимагає трьох речей: [1] Скласти чіткі правила тестів на надійність. [2] Тестуйте на правила, але також переконайтесь, що тести зрозумілі нормальним клієнтам або регуляторам на величину менше часу, ніж витрачено розробниками. [3] Будьте впевнені, що розробники та тести роблять фахівці з розробки програмного забезпечення та проблемної області.
  • Постачальник програмного забезпечення повинен взяти на себе гарантію чи інші засоби усунення несправностей програмного забезпечення.
  • Використовуйте безпечну мову, зокрема не C. SPARK пропонується.
  • Дизайн для контрактного підходу є однією з переваг SPARK. Проектування для контракту - важлива технологія для вбудовування тестів у кожну функцію / метод виклику та завжди її виконання під час виконання. Більше, ніж просте твердження () за старих часів, контракт може також включати тести на структурні наміри і переконатися, що жодне порушення не може бути допущено в більш пізні терміни циклу обслуговування, коли оригінальні розробники здебільшого перейшли на інші проекти. Є докази того, що дизайн за контрактом випускав дуже надійні програмні продукти. SPARK та його інструменти можуть бути використані для сприяння створенню тестових випадків сертифікації для спрощення процесу сертифікації.

Згідно з моєю пам’яттю, HP практикувала розробку контракту майже десять років тому. З невеликою командою, 500k рядків коду, лише 2 помилки повідомляються після доставки. Дуже вражає.

На мою думку, надійне або досконале програмне забезпечення може бути досягнуте лише у тому випадку, якщо вартість не надто висока. Каркаси або автоматики є обов'язковим.


0

Зазвичай вони мають апаратне блокування, яке використовується як безпечне відмову.

Наприклад, стандартні конструкції текстового поля зла для роботів-вбивць завжди поставляються з перемикачем kill: P


0

Кожна галузь має свій власний набір регуляторних агентств, які мають вимоги до тестування та документації щодо технічного та програмного забезпечення, що стосуються безпеки. Розглянемо цей PDF з Лабораторії андеррайтерів (UL), який впроваджує стандарт UL 1998: http://www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

У цьому документі є посилання на багато інших пов'язаних з них UL, CSA та IEC.

Зазвичай програмне забезпечення, пов'язане з безпекою, матиме надлишкові апаратні схеми або вимагатиме інших резервних функцій управління для забезпечення безпечної роботи та безпечних режимів відмови.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.