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

Самолет, в отличие, например, от веб-сайта, представляет собой систему, в которой любой сбой в некоторых системах совершенно неприемлем, поскольку ошибки, например, в мониторинге полета, могут привести к неисправности автопилота и совершению погружения. Очевидно, этого не происходит, так как блестящие инженеры Boeing и Airbus проверяют автопилот, чтобы убедиться, что он внезапно не решит, что погружение является совершенно приемлемым и безопасным маневром. Или, возможно, компьютер выходит из строя, и пилоты на более новом самолете, летящем по проводам, больше не могут управлять самолетом. Конечно, в эти системы встроены различные процедуры безопасности и резервирования для предотвращения сбоя (как программного обеспечения, так и самолета).

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

_{Я отчаянно надеюсь, что вы не все пойдете: «О, я работаю на Boeing / Airbus / (в какой-то другой компании), и это не так! Удачи в следующем перелете / посещении больницы».}

Я проделал большую работу в области промышленного контроля. Это не обязательно должно быть в такой славной индустрии, как авиакосмическая отрасль. Почти у каждой промышленной машины достаточно потенциальной энергии, чтобы вызвать серьезные травмы или смерть. Я был рядом, когда люди были ранены. Если вы проводите большую часть своего времени за рабочим столом в офисе, вы, вероятно, будете удивлены тем, насколько опасными могут быть большинство заводских работ (и, конечно, они были до недавнего времени). Теперь у нас есть лучшие методы защиты машин. Вот как это работает на практике (хотя это зависит от юрисдикции):

В США существуют стандарты OSHA и аналогичные (обычно более строгие) руководящие принципы в ЕС. Обычно они начинаются с того, что вам необходимо провести анализ риска. Это означает, что вы составляете список всех опасностей и затем классифицируете эти опасности, принимая во внимание такие вещи, как то, как часто человек подвергается риску, насколько легко избежать риска (зависит от скорости и т. Д.) И что тяжесть результата (порез, ампутация, смерть и т. д.).

Большая часть анализа связана с охраной опасностей. Если вы поместите большую клетку вокруг своей машины и плотно закрутите ее, то ваша машина считается безопасной, если компоненты машины не могут нарушить защиту. Если вам нужен инструмент, чтобы войти, это считается задачей технического обслуживания, и специалисты по техническому обслуживанию должны быть обучены тому, как безопасно работать на машине. В действительности, однако, большинство машин нуждаются в регулярном взаимодействии с операторами, поэтому мы должны поставить входные двери в ограждение или световые завесы и т. Д. Необходимо контролировать эти двери и световые завесы и подвергать опасности опасности, которым оператор подвергается. должен быть отключен «надежным контролем».

На основании этого анализа риски подразделяются на различные категории. Распространенной классификационной шкалой является категория 1 - категория 4 (на основе стандарта EN 954-1). Исходя из этих категорий, вы по закону обязаны обеспечивать определенный уровень охраны и безопасности машины.

Например, категория 4 требует, чтобы:

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

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

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

• Они предназначены для контроля двух резервных входных каналов, поэтому, если у вас есть датчик, который обнаруживает состояние неисправности (например, открыта защитная дверь), он обычно имеет два контакта с резервными цепями. Реле контролирует оба канала, и если один из них открывается, он отключает электропитание ваших приводов, но если они оба не выпадают одновременно, то он входит в состояние неисправности, и машина не может быть перезапущена до тех пор, пока не будет отремонтировано ,
• Реле также использует электрические импульсы на этих линиях и использует эти сигналы для контроля перекрещенных или закороченных проводов, поэтому оно может обнаружить неисправность проводки.
• На выходной стороне он использует набор двойных цепей для возбуждения выходных катушек, поэтому, если одна из них переходит в состояние «включено», другая должна препятствовать подаче питания на выход. Кроме того, они контролируются, и если обнаружена неисправность, это препятствует работе. Сами катушки на самом деле представляют собой реле с двойной силой, что означает наличие избыточных физических реле на выходе, а также гарантирует, что контакты на каждом отдельном реле физически связаны друг с другом, так что один контакт из, скажем, 4, не может застрять сам по себе. Они также контролируются.
• Он также включает вход для контроля вспомогательного нормально замкнутого контакта от нагрузки, которой вы управляете. Если он отключает выход, он должен видеть нормально замкнутый контакт, означающий, что он подтверждает, что он выключил контактор двигателя или что-то еще, прежде чем ему снова позволили перейти в состояние «включено».

Как вы можете сказать, это сложные устройства. Типичные затраты находятся в диапазоне от 200 до 600 долларов за каждое реле безопасности. Очевидно, что в этих устройствах есть программное обеспечение. Чтобы сертифицировать реле безопасности, вам, как правило, необходимо придерживаться такой конструкции:

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

После того, как вы спроектируете свою систему безопасности для своей машины, используя компоненты с рейтингом безопасности, вам нужно будет проверить проект и поставить печать с профессиональным инженером. Затем вы строите машину. Затем П.Энг. рассмотрим конструкцию машины, убедившись, что она была построена по проекту. Они задокументируют его и проведут некоторые тесты, чтобы убедиться, что он работает как положено. Это называется предварительным обзором (PSR) и проводится не в каждой юрисдикции. После прохождения PSR оператор может запустить машину.

В последние годы произошли некоторые революции в системах безопасности. Некоторое время никто не доверял передаче данных безопасности по сети, поэтому то, что обычно называют «распределенными системами ввода-вывода», такими как DeviceNET и EtherCAT, не допускалось в части безопасности системы. Однако последние протоколы теперь позволяют устройствам безопасности работать в этих промышленных сетях. Протоколы используют сообщения с метками времени и двойную избыточную обработку на обоих концах соединения.

Реле безопасности постепенно идут по пути птицы-додо, заменяясь более сложными ПЛК безопасности, которые похожи на способ построения логики безопасности на языке функциональных блок-схем. Опять же, эти ПЛК безопасности используют все избыточное. Когда программа утверждена, прежде чем машина будет введена в эксплуатацию, P.Eng. отметит программу и программа / ПЛК будет заблокирована паролем. Он также принимает хеш программы, и этот хеш записывается в документации (это то, что на самом деле печатает P.Eng.).

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

Существует серьезный шаг в сторону формальной проверки, а не случайного функционального тестирования.

Правительственные учреждения, такие как НАСА и некоторые оборонные организации, тратят все больше и больше на эти технологии.

Они все еще PITA для среднего программиста, но они часто более эффективны при тестировании критических систем.

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

Это зависит от того, что программное обеспечение. Например, в самолетах обычно используется обработка с двойным резервированием для критических систем; в крайнем случае может быть использовано 2 разных варианта аппаратного обеспечения и два независимо разработанных фрагмента программного обеспечения, по одному для каждого. Они оба рассчитывают и перепроверяют друг друга. Это не надежно и очень дорого.

Когда дело доходит до таких испытаний, как тестирование авиационных систем, проводится ряд тестов - тестирование систем, связанных с полетом, занимает месяцы, и, если вы вносите какие-либо изменения, необходимо провести целую серию повторных испытаний. Обычно это делается в симуляторе, который на самом деле может быть полон реальных частей самолета (например, кабины), скажем, с имитированным двигателем или подобным. Как вы можете себе представить, это также ужасно дорого построить. Изменения оцениваются по формальной программе испытаний, а затем выполняются на реальном самолете в испытательных полетах. Наряду с тем, как выполняются такие тесты, как «нарушенный функционал», именно здесь измененному элементу разрешено выполнять свои обычные функции, и все проверяется / тестируется, чтобы увидеть, что не было вредного эффекта. Это также стоит больших денег и может занять несколько недель.

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

Когда вы попадаете в медицинское учреждение, возникает целый ряд нормативных препятствий, связанных не только с тестированием, но и с процессами разработки и документацией.

Все эти поля - большой шаг вперед по сравнению с местами, где есть немного кода PHP для веб-сайта. Это медленно, кропотливо, сложно, скучно, утомительно, дотошно и очень дорого. Возьмите свои обычные затраты на разработку / тестирование и умножьте примерно на 100, и вы приближаетесь к цели.

Для программного обеспечения космических челноков НАСА чтения Они пишут Right Stuff . Для FDA (Управление по контролю за продуктами и лекарствами США) прочитайте прочитайте это

Поскольку вы уже получили достаточно хороших и информативных ответов, вот мое мнение.

Все просто - первый тест всегда проводится на самих программистах. Он имеет тенденцию поддерживать низкое количество ошибок и гарантирует, что в расчетах заработают только качественные программисты.

Критическое для жизни программное обеспечение не тестируется ни на один другой стандарт, кроме «оно, кажется, работает» , так как оно выполняется повсеместно.

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

ps Без комментариев по первому -1, но я был бы рад взять -1за каждую ссылку, которая опровергает мое утверждение.

Могу ли я получить +1 за каждую ссылку, которую я нахожу на критическое программное обеспечение, которое не было хорошо разработано или протестировано? Симсон Гарфинкель документирует десять случаев в статье о WIRED.

Существует не один ответ для всех случаев. Это зависит от конкретного производителя, чтобы решить, как разработать и протестировать свое программное обеспечение. Но весь процесс разработки программного обеспечения должен соответствовать формальным спецификациям.

Например, при создании программного обеспечения для медицинских устройств вы должны следовать стандарту IEC 62304 для программного обеспечения для медицинских устройств. (К сожалению, я могу ссылаться только на Википедию, так как она не бесплатная). Практически каждая страна в мире требует соблюдения этого стандарта.

Насколько строги эти требования, зависит от риска причинения вреда. Например, устройство жизнеобеспечения будет иметь наибольший риск причинения вреда (определенная смерть, если система выйдет из строя), тогда как система, которая работает с диагностикой заболевания, имеет меньший риск (возможная смерть, если неизлечимое заболевание не было правильно диагностировано, если система выйдет из строя).

Но в основном это говорит о том, что должна существовать прослеживаемость от требований к программному обеспечению. Вы должны выполнить проверки программного обеспечения. Это не указывает, что такое проверка. Могут быть юнит-тесты, может быть обзор кода. Для устройств с более высоким риском вы должны вручную проверить интерфейсы между программными модулями (насколько я понимаю и помню). И конечно много других правил. О, и вы должны написать много документации, чтобы документировать свою работу.

Стандарт не запрещает гибкую разработку, хотя при чтении кажется, что он написан с учетом развития водопада.

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

Используются многие методы, включая, но не ограничиваясь:

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

Но техника номер один:

• ТЕСТИРОВАНИЕ

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

Самолеты проходят несколько лет летных испытаний, когда самолет попадает в экстремальные ситуации. Это проверяет не только физическую структуру, но и программное обеспечение.

В EETimes есть статья «Идеальное программное обеспечение» Джека Гансле от 01.03.2009, 12:00 EST. Несколько моментов оттуда:

• «Теоретически, Программное обеспечение является единственным компонентом, который может быть идеальным, и это всегда должно быть нашей отправной точкой». - Это сказал Джесси Пур. Следуя его веб-странице, вы узнаете, как сделать идеальное программное обеспечение не намного дороже, чем обычное программное обеспечение.
• Есть промышленные поставщики высоконадежных ОС. В статье упоминаются Миркриум и Зеленые холмы. На веб-странице Micrium есть список стандартов для сертификации. Это должны быть процессы и правила, которым следует отрасль. Это основано на формальной валидации, но сильно отклоняется от теории.

Интересно, что в отношении коммерческого программного обеспечения данные, собранные Capers Jones, свидетельствуют о том, что «программное обеспечение в целом имеет эффективность устранения дефектов (процент ошибок, удаленных перед отправкой) на уровне 87%. Прошивка получает значительно лучшие показатели на 94%». Для меня ни один из них не является почти идеальным. В статье, упомянутой ранее автором, указывается, что команда космического челнока НАСА достигла уровня устранения ошибок 99%, но стоимость составляет около 400 миллионов в год для примерно 400 тысяч строк кода.

Более интересная статья "Программное обеспечение для надежных систем" того же автора от 1.11.2009, кажется, более актуальна. Это можно резюмировать так:

• Что касается процесса разработки, индустрия следовала DO-178B или IEC61508. Это подчеркивает тестирование с наибольшим охватом. Но мало доказательств можно найти об эффективности этого.
• Орган по сертификации, Комитет по сертифицируемым программным системам, опубликовал книгу под названием «Программное обеспечение для надежных систем - достаточные доказательства». Это хорошая ссылка.
• Книга, в основном, требует трех вещей: [1] Создать явные правила для тестов на надежность. [2] Тесты на соответствие правилам, но также убедитесь, что эти тесты понятны обычным клиентам или регулирующим органам с меньшим временем, чем затрачиваемое разработчиками. [3] Убедитесь, что специалисты по разработке программного обеспечения и проблемной области занимаются разработкой и тестированием.
• Поставщик программного обеспечения должен предоставить гарантию или другие средства правовой защиты в случае сбоя программного обеспечения.
• Используйте безопасный язык, в частности, не C. Рекомендуется SPARK.
• Дизайн для контрактного подхода является одной из сильных сторон SPARK. Проектирование по контракту - важная технология, позволяющая встраивать тесты в каждый вызов функции / метода и всегда выполнять его во время выполнения. Более простой assert () в старые времена, контракт может также включать тесты против структурного намерения и гарантировать, что никакое нарушение не может быть включено в более поздние периоды цикла обслуживания, когда первоначальные разработчики в основном переходили к другим проектам. Существуют свидетельства того, что проектирование по контракту позволило создать очень надежные программные продукты. SPARK и его инструменты могут быть использованы для оказания помощи в создании сертификационных тестов для упрощения процесса сертификации.

Насколько я помню, HP практиковала проектирование по контракту почти десять лет назад. С небольшой командой, 500 тыс. Строк кода, только 2 ошибки сообщалось после доставки. Очень впечатляюще.

На мой взгляд, надежное или совершенное программное обеспечение может быть достигнуто только в том случае, если стоимость не слишком высока. Фреймворки или автоматизация является обязательным.

Они обычно имеют аппаратную блокировку, которая используется в качестве отказоустойчивой.

Например, стандартные злые текстовые поля для роботов-убийц всегда идут с выключателем: P

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

В этом документе есть ссылки на многие другие связанные с UL, CSA и IEC.

Как правило, программное обеспечение, связанное с безопасностью, будет иметь избыточные аппаратные схемы или требовать наличия других избыточных функций управления для обеспечения безопасной работы и безопасных режимов отказа.